unlocking data with a locking enclave

专利摘要:
techniques for securely blocking and unblocking enclave data across platforms are presented. enclave data from a source enclave housed on a first computer can be securely locked to a lock enclave on a second computer, and can also be safely unlocked to a destination enclave on a third computer. the safe transfer of an enclave workload from one computer to another is disclosed.
公开号:BR112019013698A2
申请号:R112019013698
申请日:2017-12-20
公开日:2020-02-04
发明作者:Costa Manuel
申请人:Microsoft Technology Licensing Llc；
IPC主号:

专利说明:

Invention Patent Descriptive Report for ’’ UNLOCKING DATA WITH A BLOCKING ENCLAVE ”. TECHNICAL FIELD [0001] The present invention relates to secure computing systems.
BACKGROUND [0002] Safe isolated regions or trusted execution environments provide a safe container, referred to as an enclave in this document, for executing reliable code on a computer that may also have less reliable code in a region outside the isolated region. An isolated region of the enclave includes a portion of memory that is protected during the execution of the code that resides outside the enclave. The isolated memory can contain both the code and data for the enclave, and the protection of this memory may include restrictions on the execution of the code contained in the memory of the enclave in addition to restrictions on reading from writing on the memory of the enclave. Aspects of the security of the enclave, such as memory isolation and execution restrictions, can be applied, for example, through the hardware in the computer's processor. The software certificate can provide reliability in the isolated security of a particular enclave and in the enclave code that is loaded into the isolated memory region of that particular enclave. The certificate can additionally provide proof of the integrity of the hardware and software platform on which the certified enclave is running.
[0003] Enclave systems such as Microsoft's Virtual Secure Mode (VSM) and Intel's Software Guard Extensions (SGX) provide security in part by isolating an enclave from other code running in both user mode and kernel mode . Integrity and confidentiality guarantees can provide an enclave with a higher level of reliability in the authenticity of the code in
Petition 870190061562, of 7/2/2019, p. 12/142
2/101 execution in an enclave, and confidence in the safe execution of the enclave code. A guarantee of integrity can be provided through software certification for a particular enclave. Software certification can include scrambling encrypted content (instructions and data) within an enclave and can be combined with data about the enclave environment. When an enclave is used in combination with a hardware security module (HSM), such as hardware conforming to a Trusted Computing Group Trusted Platform Module (TPM) standard, the enclave can provide a level additional guarantee of safety and reliability.
[0004] In addition to the security provided by isolating a trusted local enclave from untrusted local code outside the isolation of the enclave, the software certification of an enclave can enable remote reliable computing. The certification of a remote enclave can provide confidence both in the integrity of the execution of instructions in the enclave, and in the confidentiality of data processed by the enclave. When certification of a remote enclave is provided through hardware from a trusted manufacturer, an enclave can be trusted even when the enclave resides on an unknown computer that is owned and maintained by an untrusted party. This is often the case, for example, when computing resources are rented out on a cloud-based computing resource on the Internet.
SUMMARY [0005] Methods and systems are presented for the abstraction of an enclave platform. The method may comprise the receipt, by an enclave abstraction platform, of a first request for the use of an enclave from an enclave client. The first request may be in accordance with a
Petition 870190061562, of 7/2/2019, p. 13/142
3/101 client abstraction protocol. The first request can be converted into a second request that conforms to a native enclave protocol associated with a native enclave platform. The second request can then be forwarded to the native enclave platform. The first request can be, for example, a request to instantiate an enclave, a request to verify an enclave certification report, a request to call into an enclave, or a request to allocate memory that is shared with both the enclave and the enclave client. The native platform can conform to Intel's Software Guard Extensions (SGX) enclave architecture and the native platform can conform to Microsoft's Virtual Secure Mode (VSM) enclave architecture.
BRIEF DESCRIPTION OF THE DRAWINGS [0006] FIG. 1 describes an example of a high-level block diagram of an enclave system.
[0007] FIG. 2 describes an example of a process for message transfer with guaranteed confidentiality.
[0008] FIG. 3 describes an example of a process for message transfer with integrity guarantee.
[0009] FIG. 4 describes an example of a message transfer process with guaranteed timeliness.
[0010] FIG. 5 describes an example of a process for software certification of an enclave.
[0011] FIG. 6 describes an example of the Diffe-Hellman Key Exchange (DKE) protocol.
[0012] FIG. 7 describes an example of a chain of trust for software certification.
[0013] FIG. 8 is a block diagram of software component interfaces for an example of a local enclave system.
Petition 870190061562, of 7/2/2019, p. 14/142
4/101 [0014] FIG. 9 is a block diagram of software component interfaces for an example of a local enclave system with an abstraction layer.
[0015] FIG. 10 is a block diagram of software component interfaces for an example remote enclave system with an abstraction layer.
[0016] FIG. 11 describes an example of a general purpose computing environment.
[0017] FIG. 12 describes an example of a flow chart for a method of abstraction of a native enclave platform.
[0018] FIG. 13 describes an example of a flowchart for a method of abstraction of a native enclave platform.
[0019] FIG. 14 describes an example of a flowchart for a method of performing an enclave operation with an abstract enclave identity.
[0020] FIG. 15 describes an example of a flow chart for a method 1500 of performing an enclave operation with an abstract enclave identity.
[0021] FIG. 16 describes an example of a system with abstract enclave identity equivalence.
[0022] FIG. 17 describes an example of a flowchart for parallel processing with two equivalent enclaves.
[0023] FIG. 18 describes an example of a flowchart for serial processing with two equivalent enclaves.
[0024] FIG. 19 is a block diagram of an example of a distributed data lock system.
[0025] FIG. 20 is an example of a flowchart for unlocking and blocking distributed data.
[0026] FIG. 21 is a block diagram of an example of a key vault enclave.
Petition 870190061562, of 7/2/2019, p. 15/142
5/101 [0027] FIG. 22 is an example of a flow chart for some key vault enclave operations.
[0028] FIG. 23 is an example of a flow chart for operating a key safe enclave with a safe locking key. DETAILED DESCRIPTION OF THE ILLUSTRATIVE MODALITIES [0029] An abstraction model for enclaves is released that simplifies the development of enclave clients and the software that runs within an enclave. An abstraction model can be a simplification and unification of native enclave platform architectures, such as Intel's SGX and Microsoft's VSM. An abstraction layer software component can translate communication between an enclave client and one or more native platforms, between software within an enclave and one or more native enclave platforms, and between software within an enclave and an enclave client. Such an abstraction platform can provide the benefit of enabling a single version of enclave software and enclave client software to run on multiple native enclave platforms, such as SGX and VSM. In addition to simplifying the task of writing software for enclaves and enclave clients, it allows enclave end users to run the enclave and enclave client software on a computer that supports any supported native enclave architecture without having to find versions of both enclave and enclave client software that are tailored to a specific computer's native enclave platform.
[0030] An enclave abstraction model may, for example, include primitives for: enclave life cycle management, local and remote certification of an enclave, data blocking for an enclave, program transfer control in and out of an enclave, and other security features such as monotonic counters and confidence time. An abstract identity or in
Petition 870190061562, of 7/2/2019, p. 16/142
6/101 layer of an enclave is also presented that performs the abstraction of an enclave identity in addition to a single binary or a single shuffle of the enclave content. Interfaces of software components, such as an application program interface (API) or binary application interface (ABI) are presented for the development of enclave and enclave client programs using abstraction model primitives.
[0031] An abstract identity can include a nested identity or an identity hierarchy that can be used to securely identify groups of enclave instances. An enclave instance in this document can refer to the same enclave binary code loaded into an enclave on the same machine and having the same identity. On the other hand, a new version of the binary code, or the same binary code loaded on a different machine, can be considered a different instance. These different instances can also have the same identity at a higher level in an identity hierarchy. An abstract enclave identity enables groups of related enclave binaries to be identified as related. For example, different versions of the same enclave, such as versions of enclave binaries before and after a bug has been resolved, can be given the same name, regardless of version. At a higher level of abstraction, all enclaves in an enclave family can be assigned a unique family name or identity. In this case, all enclaves that perform different but related functions can be identified together. Other layers of identity or groupings of identity are described below.
[0032] Any layer of an abstract identity can be used for various cryptographic operations, such as blocking data, certifying an enclave, or guaranteeing the timeliness of data
Petition 870190061562, of 7/2/2019, p. 17/142
7/101 (by means of monotonic counters). For example, by blocking data being produced by an enclave instance to a higher level of identity, the data can then later be safely consumed by a different enclave instance with the same higher level enclave identity. high. By blocking data for, for example, an enclave family, any enclave instance that is a member of that family, and only members of this family, will be able to unlock the data. Certification for a family identity from an enclave instance provides assurance that the enclave instance is a member of that family. Monotonic counters linked to an identity abstraction can provide a guarantee of timeliness related to all instances of enclave that are members of the same abstraction identity.
[0033] The abstraction model disclosed includes software component interfaces, such as an application program interface (API) or a binary application interface (ABI), which can simplify the development of enclave and enclave host software. . An API is a set of definitions of programming subroutines, protocols, and tools for creating software. An API can define the inputs and outputs of a software component, the types of data used by the software component, and the functionality or operation of the software component independently of any particular software component implementation. An API can be defined in a high-level computer language, such as C, C ++, C #, and the like. A formalized definition of an API can facilitate interaction between software components, for example, two software components written at different times or by different authors. An API can be formalized in part with a description language
Petition 870190061562, of 7/2/2019, p. 18/142
8/101 interface (IDL) such as Microsoft Interface Definition Language (MIDL) or Object Management Group (OMG) IDL. An ABI is also an interface between software components, but it is an object code interface. For example, an ABI can be entry points (or instruction addresses) for object code resulting from the compilation of an API source code implementation along protocols for using those entry points, such as protocols that specify records machines that hold arguments when entry points are called.
[0034] In addition to enabling interaction with different levels of enclave identity as described above, an enclave API can abstract the differences between enclave platform architectures, for example, between architectures for secure isolated execution provided by Software Guard Extensions ( SGX) from Intel, Virtual Secure Mode (VSM) from Microsoft, and ARM Trustzone, Secure Encrypted Virtualization (SEV) from AMD, and architectures based on Programmable Port Field Arrays (FPGAs). APIs include interfaces to an enclave platform that abstracts some details from abstracted enclave architectures. These enclave platform interfaces include an enclave host API, an enclave platform API, and a remote certification API. The enclave host API can be used by an unreliable hosting process to manage the life cycle of an enclave as well as provide communication to and from an enclave. The enclave platform API can be provided by the trusted enclave platform for the enclave, and may include security primitives for certification, blocking, and communication with untrusted code that runs on the computer hosting the enclave computer, as well as core runtime support such as memory management and segment scheduling. The remote certification API can be
Petition 870190061562, of 7/2/2019, p. 19/142
9/101 used to perform a remote certification, when an enclave and its client are not hosted on the same computer. For example, the remote certification API can be used by a local client to verify data originating (or having been sent) from an enclave with a certain identity that runs under isolation provided by an enclave platform on a remote computer. More generally, the remote certification APi can be used to establish secure communication channels between a local client and a remote enclave.
[0035] Enclaves generally provide solutions to problems that are specific to, and stem from, the realm of computing technology. More specifically, enclaves provide a mechanism for segregating trusted code from untrusted code where both trusted and untrusted code segments reside within the address spaces of a single computer processor. For example, enclaves provide a security solution to the problem of potentially untrusted code (such as code that potentially contains both bugs or viruses) running on the same general purpose computer as code that must access private or sensitive data. Disclosure modalities also provide improved solutions to such security problems that arise in the field of computing technology, including: simplifying software development to enable a single enclave or enclave client to be authorized for multiple native enclave platforms; simplifying enterprise computer management by reducing the number of software components that can be customized for specific hardware features on a particular computer; and enabling new secure computing scenarios with distributed data blocking, such as secure enclave processing distributed across enclaves hosted on
Petition 870190061562, of 7/2/2019, p. 20/142
10/101 multiple computers.
[0036] FIG. 1 describes a high-level block diagram of an enclave system along with some relationships of trust. The enclave system 100 includes an enclave 176 (alternatively called an enclave container or a safe execution environment), which includes a secure isolated memory region containing code 180 and data 182. Code 180 can be public or private , and data 182 can be public or private. For example, the private code or data may belong to (or be private to) a data owner 142, while the public code or data may have been provided by another party, such as a software provider 148. In one embodiment, the code that runs inside an enclave container 176 can be completely public and not private, while the data that the public enclave code uses as input or outputs can be private. In another mode, the reverse is possible, where the code is private while the data is public. In yet another embodiment, both the code and the input data can be public, while the output of the code execution with the input data can be private. Other combinations of public and private codes, input data, and output data are possible.
[0037] Enclave container 176 is hosted on trusted hardware 172, which can simultaneously host untrusted software 174. A primary purpose of enclave system 100 may include at least one aspect selected from a list consisting of: maintaining code 180 integrity, maintaining code 180 confidentiality, maintaining data integrity 182, and maintaining data confidentiality 182. Protecting the contents of enclave 176 from untrusted software 174 (for example, disclosure to the software not
Petition 870190061562, of 7/2/2019, p. 21/142
11/101 reliable, modification by unreliable software, or the like) may be an objective. Trusted hardware is built by a manufacturer 162, and is owned and managed by an infrastructure owner 152.
[0038] Enclave client 104 can be a process or program external to the enclave container for which enclave 176 performs its computations with code 180 and data 182. In a local enclave mode, enclave client 104 also it may be running on 172 trusted hardware. In a remote enclave mode, the enclave client may run on one computer while the 172 trusted hardware is a different, remote computer, connected to the enclave client computer via a network. In the case of the local enclave, the enclave client process can also the enclave host process of the enclave container 176 where the enclave client process can manage the creation of the local enclave 176. In the case of the remote enclave, the enclave 176 can, for example, run on an internet cloud computer where the owner of infrastructure 152 is a provider of cloud computing services, and cloud computing includes reliable hardware 172 which is manufactured by manufacturer 162.
[0039] Enclave client 104 may include a definition method 106 to define a computation requested by enclave 176. Definition method 106 may include the creation of secure enclave container 176, the instantiation of the enclave (for example, when sending a request to untrusted software 174 to ask for the enclave instantiation), which may include copying the binary code to the secure container, and causing or requesting computation in the enclave, for example, by calling a method in the code copied to the secure container. The computation requested may include execution of code 180, and data 182 may be inserted into, or may be a result of,
Petition 870190061562, of 7/2/2019, p. 22/142
12/101 the computation requested. The insertion of data for the requested computation can be encoded when external to the enclave, and the encoded input data can be decoded before being used inside the enclave. Once enclave 176 has completed the requested task, the data representing the result of the task is encoded and sent back to enclave client 104. When enclave client 104 receives the encoded results, a verification method 108 can confirm the integrity and timeliness of the results received. A single software vendor 148 can provide both code 180 to run within enclave 176, and at least a portion of verification method 108 that runs as part of enclave client 104.
[0040] The data owner's confidence in the privacy of a private data portion 182 and a private code portion 180, as well as confidence in the correctness of the results produced by enclave 176, can be based on trusted relationships. For example, a data owner 142 can trust enclave client 104, which may not be running itself within an enclave container. The data owner can, in addition, trust the enclave software vendor 148. And the data owner can trust the manufacturer of trusted hardware 172. Trusted hardware 172 can take many forms depending on the enclave architecture used, and can include a hardware security module (HSM), where HSM conforms, for example, to the Trusted Platform Module (TPM) standard. Trusted hardware 172 may include, for example, a TPM and may otherwise comprise only the hardware. For example, a trusted hardware implementation 172 using Microsoft's VSM enclave architecture may include a product processor with instructions for operating system update instructions and a TPM. The VSM enclave architecture of
Petition 870190061562, of 7/2/2019, p. 23/142
10/13
Microsoft can include a hypervisor to manage guest partitions (virtual processors), and the hypervisor can expose hyper-call interfaces to the guest partitions to allow the guest partitions to interact with the hypervisor. An enclave container in a Microsoft VSM architecture can be implemented as a special type of guest partition. An example of reliable 172 hardware with Intel's SGX enclave architecture may include a processor with specific enclave instructions and special security functionality.
[0041] An enclave, such as enclave 176, can provide an isolated execution environment that can protect code or data, such as code 180 and data 182, by providing a region of memory with restrictions for reading, writing, or execution from the protected region. This protected memory region is a secure container for confidential codes and data. Restrictions on executions from a protected memory region of the enclave may include restrictions on executing transfers, such as jump or call instructions, between the code outside the enclave and the code inside the enclave, and vice versa. Different restrictions can be applied between a call inside the enclave from outside the enclave and a call outside the enclave to the inside of the enclave. The application of such transfer execution between the inside and outside of an enclave can be provided by hardware, for example with product virtualization hardware technology or with specialized hardware such as Intel's SGX platform.
[0042] FIG. 2 describes an example of process 200 for message transfer with guaranteed confidentiality. The guarantee of confidentiality provides some level of assurance that communication between the two parties, such as Anne 210 and Bem 230,
Petition 870190061562, of 7/2/2019, p. 24/142
14/101 in this example, it remains hidden from third parties when messages are passed through an unprotected or public medium, such as network 218. In this example, Anne 212 would like to send a confidential message to Bem 230. The message block 212 containing confidential data is encrypted using public key 216 by an encryption operation 214. The encryption operation 214 can be, for example, the Advanced Galois / Counter Mode Encryption Standard (AES-CGIVI), but also it may be an encryption operation known to experts in digital encryption technology. Encrypted block 220 can pass through network 218 to Ben, where encrypted block 234 is decrypted with private key 236 to produce decrypted message block 232 for Ben. With a careful selection of keys and encryption algorithms, as is known in computer data encryption technology, the message can remain confidential even when it passes through a public network.
[0043] FIG. 3 describes an example of process 300 for message transfer with integrity guarantee. Integrity assurance provides some level of assurance that communication between the two parties, such as Anne 310 and Ben 350, in this example, is not manipulated or otherwise altered when messages are passed through a medium of unprotected or public communication such as network 340. In the example of FIG. 3, Anne 310 sends a message 314 to Ben 350 in such a way that there is confidence that message 314 will not be manipulated or otherwise corrupted when Ben 350 receives it. To provide this guarantee of integrity, a secure scrambling process 316 operates on message 314 to produce a scrambled value 318. The scrambled value 318 is then signed by the
Petition 870190061562, of 7/2/2019, p. 25/142
15/101 signature 320 using Anne's private key to produce a signature 342. The signature 342 can be sent over a public network 340 or other unprotected communication process along with a copy of message 314 as a message 344. Ben, then he receives message 354 for which Ben would like to check integrity, so that Ben can be confident that message 354 is the same message 314 that Anne sent after passing through an untrusted network 340 To verify the integrity, the received message 354 is processed through a secure scramble 356 that is identical to the secure scramble 316 to produce a scramble value 358. The received signature 342 is verified through a 360 signature verification process using Anne's public key. The scramble value 318 that is extracted from signature 342 is then compared to the scramble value 358 to check 380 whether the signatures are the same. If they are the same, the message is accepted 384 as having integrity. Alternatively, if message 314 was changed in any way before it was received as message 354, then the signature will not be correct and the message will be rejected 388.
[0044] In some embodiments, secure scrambling 316 and secure scrambling 356 can be a function of cryptographic scrambling. The cryptographic scrambling function is a one-way function that maps data of arbitrary size to a one-bit string (usually much smaller) of a fixed size. The output of a scramble function can be called as a scramble value or, simply, a scramble. A good scrambling function will be one way in which it will be difficult to determine the arbitrarily sized input given only at the output of
Petition 870190061562, of 7/2/2019, p. 26/142
16/101 shuffling. With a good scrambling function, even a small change in the input will produce a change in the output.
[0045] A communication system can combine guarantees of confidentiality and integrity. For example, the encryption of the message block of FIG. 2 can be combined with the message scrambling signature of FIG. 3. The combination system may require two sets of private / public key pairs, one for the issuer and one for the receiver. A combination system can use a private key at the receiver to encrypt the message (Ben's private key in FIG. 2), while using another private key to sign the message scramble (Anne's private key in FIG. 3) .
[0046] FIG. 4 describes an example of process 400 for message transfer with guaranteed timeliness. The timeliness guarantee provides some level of assurance that when multiple messages are sent from one party to another, such as from Anne 410 to Ben 450, in this example, the message received at the recipient is the most recent message. A guarantee of timeliness can be built on a guarantee of integrity, and can prevent replay attacks. With a guarantee of integrity, it is difficult for a third party with ominous intentions to create its own message and send it to Ben so that Ben understands that the message was created by Anne. However, a third party can take a message actually created by Anne, perhaps seen at one point as having been sent over a public network, and the third party may send it back to Ben at another time (for example, a replay of the message). Ben will determine that the message was actually created by Anne (because she was), but Ben will not know that Anne is not the person who sent the message at that time. This can be called a replay attack on Ben or Anne by the third party.
Petition 870190061562, of 7/2/2019, p. 27/142
10/171
FIG. 4 is an example of a solution to prevent replay attacks by providing a guarantee of timeliness using nonces and timing. A nonce is a random, single-use number coupled with a system to ensure that the same number will never be used as a nonce more than once. In some systems a nonce can simply be a monotonically increasing number, so that every number used is higher than all the other numbers that came before it.
[0047] In FIG. 4, message 414 from Anne can be sent over a public network 430 as message 436 together with a nonce 434 and a time stamp 432. Nonce 434 is generated by a cryptographically secure pseudo-random number generator (CSPRNG) 426, and time stamp 432 is produced by a synchronized clock 424. There are many CSPRNG systems that are known to those of skill in digital encryption technology. The synchronized clock 424 on the Anne side of the network 430 is synchronized with the synchronized clock 480 on the Ben side of the network. On Ben's side, when a message 454 is received, the tracking nonce 434 is stored in a cache of recent nonces 470. The timeliness of the received message 450 can be verified with two tests. First, nonce 434 is tested on box 460 by comparing nonce 434 with the recent nonce cache 470 to determine whether the currently received nonce 434 has been sent previously. If the received nonce 434 has already been sent previously, message 454 is rejected as a replay message in box 468. If the received nonce 434 has not been sent previously, the message is determined to be OK in box 464 for this first test. Second, the received time stamp 432 is compared to the local synchronized clock 490. If the time stamp is recent, message 454 is determined to be acceptable in box 494, contrary to
Petition 870190061562, of 7/2/2019, p. 28/142
18/101 message 454 is rejected as expired in box 498. The amount of delay tolerated when determining whether a recent time stamp is recent in box 490 may depend on the expected clock slope between synchronized clock 424 and synchronized clock 480 and time delays in message processing and transmission over the 430 network.
[0048] A communication system can combine a guarantee of timeliness with one or both a guarantee of confidentiality, as in FIG. 2, and a guarantee of integrity, as in FIG. 3. In a system that combines all three, message 436 sent over network 430 will be an encoded version of Anne's original message 414, and a signature comprising a signed scramble of message 414 would be included along with a 432 time stamp, a nonce 434, and message 436.
[0049] FIG. 5 describes an example of process 500 for software certification of an enclave. Software certification, when combined with a key agreement protocol such as that of FIG. 6, you can assure a verifier that a shared secret has been established with a specific piece of software that is hosted inside an isolated container created by trusted hardware. In the embodiment of FIG. 5, an enclave client 510 (the certification verifier) may wish to use the enclave's secure computing services on the trusted platform 530. The trusted platform 530 is hosted on a computer (not designed) in such a way that the trusted platform 530 can understand a subset of the host computer. The trusted platform 530 can comprise hardware elements and software elements of the host computer. The enclave comprises a secure enclave container 536 and the code and data within it, such as public data and code 538 and data and code
Petition 870190061562, of 7/2/2019, p. 29/142
19/101 secret 542.
[0050] Three processes are combined in process example 500: a key change process that produces the combined key SK; a certification process for the certification of the enclave enclave 510 on the trusted platform 530; and secure computing are done. The SK shared key from the first process is used for secure computing communication inputs and outputs. When changing the key, the enclave client computes g ^A , stored in box 512, from the enclave client's private key A and a g generating function, for example, as described below for the Diffe- Hellman (DKE) of FIG. 6. The computed ^A is then sent in message 520 to trusted platform 530. Message 520 can be sent securely without coding and before certification is complete. The software within the secure enclave container 536 can use an enclave private key B to compute g ^B using the same g generating function. Both B and ^B can be stored in the enclave container in box 540.
[0051] To certify the identity of the enclave (to provide assurance that code is executed inside the secure enclave container 536), a 522 certification message is sent to the 510 enclave client. A certification message can be a message special signed for integrity as in FIG. 3. The special message may contain identity information about the enclave. When combined with DKE as in the embodiment of FIG. 5, the special message can also include key change parameters. In the embodiment of FIG. 5, the initial state 538 of the secure code enclave container 536 of public code and public data is used as an enclave identity, although other identities are possible. Instead of sending the complete 538 initial state in one
Petition 870190061562, of 7/2/2019, p. 30/142
20/101 certification message, a shuffle from the initial state, M Hash (lnitial State), is sent. The 522 certification message includes the message contents (M eg ^B ), and a signature of the message contents (SignAK (Hash (g ^B ), Μ)). The signature of the message contents can be created, for example, through the software inside the secure enclave container 536 requesting the trusted platform 530 that hosts the enclave to certify a scrambling of the computed g ^B and the identity of the enclave. The trusted platform 530 can do this by providing a subscription using the platform certification key (AK) 532 to produce SignAK (Hash (g ^B ), M). In this example, the enclave identity is an initial state 538 M scramble, but other identity claims are possible. This SignAK signature certification (Hash (g ^B ), M) links the g ^B value to the M enclave identity and also links both g ^B and M to the trusted platform 530. The 510 enclave client can then verify the certification message when verifying subscription certification and enclave identity. The signature can be verified as in FIG. 3 using a public key that corresponds to the AK certification key. Signature verification can provide a guarantee of the integrity of the enclave identity in the message certification. The enclave identity can be verified by comparing the identity information in the message certification with an independently known identity value. For example, if the identity information in the message certification is a scramble from the initial state of the enclave, the enclave client 510 may know the scrambling of the initial state, or may be able to calculate such scrambling from a known initial state, and this value can then be compared to the identity value provided in the message certification.
[0052] To produce the SK shared key, both the
Petition 870190061562, of 7/2/2019, p. 31/142
21/101 enclave 510 and the code inside the secure container 536 can generate g ^AB (the generating function g applied to the product of A times B) which can serve as the shared key SK. The SK shared key can be used to encode messages for confidentiality between the enclave client 510 and the enclave, for example, to send input data to, and output data from, the code within the 536 enclave container. Note that the shared key is produced independently on each side of the communication channel in boxes 540 and 514 without either the enclave client or the enclave knowing the other's private key. For example, in the embodiment of FIG. 5, the secret data and code can be provided securely by the enclave client 510 by encrypting the secret data and code with the previously established shared key SK, producing EncsKÍsecret code / data) before sending it in a 524 message to the trusted platform 530. In other embodiments, secret data and code 542 executed on or used by a secure enclave container 536 can originate from other locations. A secure computation can be performed inside the secure enclave container 536 using secret data and / or code 542 to produce a computation of the result 544. The computation of the results 516 can then be communicated securely back to the customer enclave 510 when encrypting the results with the shared SK key (EncsK (results)) before sending them to the enclave client in message 526.
[0053] The processes of FIG. 5 described above provide a guarantee to an enclave customer that he is communicating with a “real” enclave of a certain identity, and that the enclave is protected by the enclave platform. This does not provide any guarantee for the code within the enclave container about the entity on the other side of the communication channel. In an alternative mode
Petition 870190061562, of 7/2/2019, p. 32/142
22/101 (not described), such a guarantee on the enclave client can be provided by running the enclave client as an enclave itself. In this alternative modality, the enclave client can request the trusted enclave platform for a signature on the scrambling of g ^A , which can then be verified by the other enclave.
[0054] A certification can be done locally or remotely. In FIG. 5, the enclave client 510 may or may not reside on the same computer as the trusted platform 530, such that communication between the enclave client 510 and the trusted platform 530 can occur within a single computer (for example, when passing data buffers between different processes on the same computer), or it can occur on a computer network that connects the enclave client 510 to the trusted platform 530. Local certification can be performed when the enclave client 510 and the trusted platform 530 are hosted on the same local computer. The artifact, or result, of the local certification is called a certification report, and is SingAK (Hash (g ^A ), M) in the example in FIG. 5. Remote certification can occur when enclave client 510 and trusted platform 530 are hosted on different computers. The artifact, or result, of remote certification is called a certification quota, which in some cases can be very similar or identical to a local certification report. In other cases, a certification quota may include an additional trust artifact related to the computer or native platform that is providing the quota. Such an additional trusted artifact may include a host health certificate such as a TCG log associated with a TPM. The certification of an enclave can be performed at any layer of an enclave identity. An enclave can have a hierarchical or nested identity, and certification for higher levels of identity can certify that an instantiated enclave is a member of
Petition 870190061562, of 7/2/2019, p. 33/142
23/101 a progressively larger group of potential enclave instantiations as the level of identity increases. The higher levels may correspond to a superset of potential lower-level enclave instantiations. An example hierarchy of identities can include, from the lowest, most specific level to the highest, less specific levels can be: ExactHash, InstanceHash, ImagelD, FamilylD, and AuthorlD.
[0055] The identity of an enclave can be derived from binary files (the enclave binaries) loaded in the secure container of the enclave. An enclave binary can be signed by its author using an author's private key. For an ExactHash level certification, the initial state 538 used to compute a certification report (the input to a scramble function to produce a certification report) can include the entire contents of all the binary files loaded into the secure container 536, except for the binaries associated with the trusted platform 530.
[0056] Certification at the InstanceHash identity level may include a subset of the initial state 538. The subset can be specified at the time the enclave binary files (the binary files), which are loaded into the secure container 536, have been originally signed by the author of these enclave binary files. For example, a first (or primary) enclave binary file may include a list of identities from other enclave binary files on which the first enclave binary file depends. For each listed identity, a flag can be included in the first binary file to indicate whether or not each listed binary file is measured by the scrambling function to produce an InstanceHash certification report.
[0057] Certification for higher levels of an enclave ID
Petition 870190061562, of 7/2/2019, p. 34/142
24/101 may not include the execution of full contents of any enclave binaries through the scrambling function. Instead, only a data structure of the IDs can be performed through the scrambling function. For example, an enclave binary file may include a list of higher-level enclave identifiers, such as universal unique identifiers (UUIDs), which indicate: a unique image ID (ImagelD) for that particular enclave binary file ; a unique family ID (FamilylD) for a group of enclave binary files that includes that particular enclave binary file and that were created by the same author; and a unique Author ID (AuthorlD) for a group of enclave binary file families that were created by the same author. ImagelD, FamilylD, and AuthorlD can be signed by the author of an enclave binary at the time the binary was originally signed. Impersonation of enclave identities can be avoided where the enclave client can access the enclave binaries and verify the signature of the author on those binaries by using the author's public key (or a public key associated with the author). This verifies the integrity of the enclave binaries, including any identities at a higher level signed by the author, as having been created by that enclave author.
[0058] FIG. 6 describes an example of a Diffe-Hellman (DKE) 600 key change protocol. DKE is an example of a process for establishing a shared key K through a communication channel with only a guarantee of integrity; other processes for creating shared keys known in digital encryption technology can be used. In the example DKE of FIG. 6, a secret key K is shared between Anne 610 and Ben 650 without K ever communicating explicitly through a public (insecure) medium between Anne 610 and Ben
Petition 870190061562, of 7/2/2019, p. 35/142
10/25
650. Before the process begins, 1) a large prime number p and 2) a g generator in Zp can be established and known to both Anne and Ben. The process then begins with both Anne and Ben choosing a random number between 1 and p. Anne's random number is A, chosen in box 612, and Ben's random number is B, chosen in box 652. Anne uses her random number to compute g ^A mod p in box 614, and transmits that quantity in box 616 which is received by Ben in box 656. Ben uses his random number to compute g ^B mod p in box 654, which is transmitted in box 656 to Anne and received in box 618. Anne can produce the shared key K as (g ^B mod p) ^A = g ^AB mod p in box 620 and Ben can produce shared key K as (g ^A mod p) ^B = g ^AB mod p in box 660. In order to prevent man-in-themiddle attacks, communication between Anne and Ben via an unprotected network from boxes 616 and 658 can include a guarantee of message integrity, for example, created using a process such as that of FIG. 3.
[0059] FIG. 7 describes an example of a 700 chain of trust for software certification. The software certification chain of trust can be rooted in a signature key owned by the trusted platform manufacturer, such as FIG 530 trusted platform. 5. The trusted platform can include hardware components such as a secure processor or a hardware security module (HSM), and therefore, the manufacturer can be a supplier of computer hardware and can also provide the software for the trusted platform. The manufacturer can be trusted through verifier 702, and the verifier can know the public key PubRK 732 from the root key of manufacturer 736. The enclave client 510 of FIG. 5 is an example of a 702 checker that may wish to have guarantees on a 708 safe container. The manufacturer can act as
Petition 870190061562, of 7/2/2019, p. 36/142
26/101 a certification authority and provide each instance of the trusted platform that produces, for example each secure processor, with a single 722 certification key, which is used to produce the certification signatures. The manufacturer also issues a 728 endorsement certificate for each 722 certification key. The 736 root key includes a PrivRK 734 private key that is used to sign the 728 endorsement certificate. Signing the endorsement certificate provides a guarantee of integrity , for example, as shown in FIG. 3.
[0060] The 728 endorsement certificate includes a PubAK 724 public key from the 722 certification key. The 728 endorsement certificate may indicate that the 722 certification key must be used for software certification, and can be communicated to verifier 702. The verifier can be any entity that wishes to verify a certification of the secure container 708, for example, the verifier 702 can be the enclave client 510 of FIG. 5 that you want a secure computation to be performed inside the 708 secure container. Verifier 702 can inspect the endorsement certificate using PubRK 732 to verify the integrity and origin of the endorsement certificate. The verifier can also extract PubAk 724 from the endorsement certificate. The endorsement certificate can be associated with a certification policy, which may require that the 722 certification key is used only to produce certification signatures and that the PrivAK 726 private key of the 722 certification key is kept exclusively in storage that is separate from the memory of the general access computer of the trusted platform, such as in the storage of 730 manipulation-resistant hardware. The manipulation-resistant hardware can be, for example, hardware that conforms to the trusted platform module (TPM) standard .
Petition 870190061562, of 7/2/2019, p. 37/142
27/101 [0061] A secure container 708 can be instantiated on the trusted platform 736. Instantiation of the secure container 708 can include the definition of an isolated memory space for the secure container that is restricted to access unsafe processing. Insecure processing may include, for example, access from outside the trusted platform, but on the computer hosting the trusted platform, or access from inside other secure containers inside the trusted platform. Instantiation of secure container 708 can also include loading data and public codes into the secure container, for example, the initial state 535 of FIG. 5.
[0062] Instantiation of the 708 secure container can exchange keys with verifier 702 to establish a shared key for confidential communication. The key exchange process can be the key exchange process of FIG. 5 or the DKE process of FIG. 6. The verifier sends the key exchange message 1 704 to trusted platform 736, for example, as in box 616 of FIG. 6, and the trusted platform 736 sends the key exchange message 2 706 back to verifier 702, for example, as in box 658 of FIG. 6.
[0063] The 710 signature certification can be created after the 708 secure container is instantiated and the key exchange is complete. The instantiated secure container 708 can be measured by performing a cryptographic scrambling function on all or part of the secure container. This may include performing the scrambling function on the contents of the isolated memory, and on the binary files that are loaded into the isolated memory, and any other memory associated with the trusted platform that is used or affected during the instantiation of the secure container, or any subset or portion thereof. The exit from running this
Petition 870190061562, of 7/2/2019, p. 38/142
28/101 scrambling function is measurement 712, which is part of the 710 signature certification. A cryptographic scrambling of key exchange messages 704 and 706 can also be included in the 710 signature certification, described as data 714. Measurement 712 and data 714 can be signed using the private certification key PrivAK 726. The signature certification can then be sent to verifier 702 together with measurement 712 and data 714. The verifier can verify the integrity of the signature certification using PubAK 724 from the endorsement certificate, which, in the example of FIG. 7, also allows verification of the integrity of measurement 712 and data 714. Verifier 702 can verify the integrity of safe container 708 by comparing measurement 712 with an expected result (the expected result determined, for example, by locally executing the same measurement shuffle 712), and verify that the signature certification was created for this particular verifier communication path instance 702 when inspecting data 714 (for example, due to the shuffling of data 714 being linked to key exchange message 2 706). After these verification and verification operations of the above endorsement certificate, the verifier now has some guarantee that it can establish a communication having both confidentiality and integrity with the 708 secure container using an established shared key, that the trusted platform hardware can be trusted according to its manufacturer, and that the software status of the trusted platform used to create the secure container is known. The verifier 702 is now ready to request secure processing within the 708 secure container using private code and / or private data. ENCLAVES AND PRIMITIVES ABSTRACTION PLATFORM [0064] FIG. 8 is a block diagram of
Petition 870190061562, of 7/2/2019, p. 39/142
29/101 software components for an example of a local enclave system. The enclave system 800 includes a computer 810 with a native enclave platform 812 that hosts the enclave 814 and an enclave client 816. The native platform 812 can be a hardware and / or software component based on, for example, SGX from Intel or VSM from Microsoft. Enclave 810 can be enclave 176 of FIG. 1. A native protocol 844 for enclaves can be used for communication between enclave 814, client 816, and native platform 812. As described in FIG. 8, native protocol 844 includes interface 820 in the enclave 814, interfaces 822 and 824 on the native platform, and interface 826 on the client. These interfaces can be APIs or ABIs in software components.
[0065] The use of these software interfaces 820, 822, 824, and 826, may include a transfer of execution control between the software components. The transfer of control may include executing a call or jump instruction to an entry point (an address of an instruction) in the software component to which the control is being transferred. For example, if native platform 812 is a software component, transfer of control from native platform 812 to client 816 can occur via software interface 826 when a call or jump instruction on native platform 812 is performed specifying an address contained in client 816 to which you must call or jump. The address specified within the 816 client can be an entry point for a function or method on the 816 interface. The transfer of control is indicated by an arrow in FIG. 8, for example: from the native platform 812 to the enclave 814 through the interface 820; from enclave 814 to native platform 812 through interface 822; from client 816 to native platform 812 through interface 824, and from native platform 812 to client 816 through
Petition 870190061562, of 7/2/2019, p. 40/142
30/101 through interface 826. A native protocol 844 can include communication standards through interfaces 820, 822, 824, and 826.
[0066] In some embodiments, the native platform 812 can be implemented at least in part as a hardware component, for example, with special processor instructions to manage an enclave. Such special hardware instructions may be executed as part of a software component of a native 812 platform. In alternative modalities, there may be no software component for some or all of the functions of the native 812 platform. native platform 822 and 824 can be hardware instructions instead of software entry points, so a native platform 812 function can be used by enclave 814 or client 816 or can be used to execute a special hardware instruction at the instead of enclave 814 or client 816, respectively, instead of executing a call or jump instruction.
[0067] In some modalities, the client 816 of the enclave 814 may itself be an enclave. For example, an 816 enclave client can use the 824 interface to request that the 814 enclave be created. In these modalities, the communication between the enclave 814 and the client 816 through the native platform 812 is, in fact, the communication between two enclaves. When the 816 client is also an enclave, the 816 enclave client can also use the 822 interface and expose an 820-like interface (not described).
[0068] FIG. 9 is a block diagram of software component interfaces for an example of a local enclave system with an abstraction layer. The enclave system 900 includes an abstraction platform 912 to translate between the native protocol 944 and the abstraction protocols 940, 942. The native platform 918 can
Petition 870190061562, of 7/2/2019, p. 41/142
31/101 be similar to the abstraction platform 812 of FIG. 8, and interfaces 928 and 930 can combine the functions of interfaces 820, 822, 824, and 825 of FIG. 8. The enclave abstraction protocol 940 includes interfaces 920, 922 for enclave 914, while the client abstraction protocol 942 includes interfaces 924, 926 for client 916. As in FIG. 8, client 916 running on computer 910 may require the creation of enclave 914 through interface 924. An abstraction layer 912 may cause the creation of enclave 914 using the native protocol 944 and interfaces 928, 930, with the native platform 918. Client 916 and enclave 914 can use abstraction protocols 940 and 942 when native platform 918 and native protocol 944 are based on different enclave architectures, such as Intel's SGX or Microsoft's VSM. As in FIG. 8, client 916 of enclave 914 may itself be an enclave, and native platform 918 may include hardware and / or software components.
[0069] Enclave 914 and client 916 may not communicate directly and may instead communicate only through the 912 abstraction platform. Direct communication may not be possible or desired, for example, due to the isolation of enclave memory 914. Isolating the enclave memory can prevent reading from, writing to, or executing (jumping in or out of) the enclave's isolated memory.
[0070] Enclave 914 may include instructions located within a secure enclave container on computer 910. Client 916 may include instructions located in the memory address space of computer 910, but outside the secure container of enclave 914. The 912 abstraction platform can be implemented in a variety of ways, including as instructions that are inside or outside the secure container of the 914 enclave, and may also include instructions executed from within hyper-calls. In the case where
Petition 870190061562, of 7/2/2019, p. 42/142
32/101 abstraction platform 912 is included, at least in part, within the secure container of the 914 enclave, the abstraction platform code within the secure container may have been created separately from the rest of the 914 enclave code and may only interact with other enclave code through public APIs / ABIs. Such an abstraction platform code may be statically linked or dynamically linked to the rest of the code within the secure enclave container. The statically linked abstraction platform code can be an object code that is associated with the abstraction platform and is included (statically linked), along with code that is more specific to the 914 enclave, in a binary image to from which the 914 enclave can be instantiated. In the case of a dynamically linked abstraction platform, the enclave code that is more specific to the 914 enclave and the code more generally associated with the abstraction platform can have their sources in separate binary images. For an example of dynamic mode connection, see FIG. 14.
[0071] FIG. 10 is a block diagram of software component interfaces for an example remote enclave system with an abstraction layer. The remote enclave system 1000 includes an enclave 1014 on a computer 1010, and a client 1056 of the enclave 1014 on a separate computer 1050. The combination of the client tip 1016 and the remote abstraction platform 1052 can facilitate interaction between the enclave 1014 and client 1056. Many elements in the computer 1010 can be identical or similar to the identically named elements of the computer 910 of FIG. 9. In particular, the abstraction platform 1012, protocols 1040, 1042, 1044, and native platform 1018 can be similar or identical to the corresponding elements 912, 940, 942, 944, and 918, respectively.
Petition 870190061562, of 7/2/2019, p. 43/142
33/101 [0072] Client endpoint 1016 can communicate with remote abstraction platform 1052 through network communication 1080. Remote client protocol 1082 and interfaces 1064, 1066, can be similar to the abstraction protocol of client 1042 and interfaces 1024, 1026. However, the remote client protocol may include additional functionality for remote execution. For example, a 1064 interface method such as CreateEnclave to request the creation of an enclave may additionally include the ability to specify an enclave host computer, such as a 1010 computer, where an enclave is requested to be created. A 1014 enclave certification quota provided to client 1056 via a remote client protocol can be provided instead of, or in addition to, a certification report. Computer 1050 with client 1056 may or may not include a native enclave platform1058. If native platform 1058 is present, it may or may not conform to native enclave example architecture platform 1018, and therefore native protocol 1044 and remote native protocol 1084 may not be the same.
[0073] In an alternative modality (not described), the client tip 1016 may not exist, and the abstraction platform 1012 may communicate directly with the remote abstraction platform 1052 through a network.
[0074] Enclave abstraction protocols, such as 940, 942,1040, 1042, 1082, of FIGS. 9 and 10, can include a variety of interface methods or entry points for managing and using enclaves that are built on various native platforms, such as Intel's SGX and Microsoft's VSM. These methods can provide enclave primitives that can be implemented on various native platforms, therefore, providing an “abstraction” from native platforms. The enclave primitives disclosed here include cycle management
Petition 870190061562, of 7/2/2019, p. 44/142
34/101 enclave life, certification, data lock, transfer of control, monotonic counters, and reliable time.
[0075] Primitives for enclave lifecycle management can include methods to cause an instantiation or termination of an enclave such as enclave 914. Lifecycle management primitives can be a part of the client abstraction protocol 942, and, more specifically, can be implemented by an abstraction platform 912 as part of interface 924 for use by client 916.
[0076] A method for instantiating or creating an enclave may include specifying an executable image of the code and / or data to be loaded into the isolated memory of the secure enclave container. This code, before or after being loaded into the enclave container, can become part of an initial state used for the certification of the instantiated enclave (as explained above with respect to FIG. 5). For example, an enclave executable image (an enclave binary) can be specified by an enclave client by providing a pointer to a memory buffer that contains the executable image. Alternatively, an enclave image can be specified by specifying a file in a file system containing the enclave binary. In some embodiments, the specified enclave image can be encoded; in other modalities, the enclave may not be encrypted; in other modalities, the enclave can be partially encrypted. The measurement of the enclave binary for certification can take place over an encrypted executable image or after decoding.
[0077] The code and / or data to be initially loaded into an enclave can be indicated by specifying a file containing a primary image of the enclave. In addition to this code and / or data, a primary enclave image may include additional metadata, such as
Petition 870190061562, of 7/2/2019, p. 45/142
35/101 as a desired size of the enclave (the amount of memory required within the enclave container), locations of entry points within the code in the file, and a list of dependent image files. Dependent image files are other (non-primary) image files that can also be loaded into the enclave along with the code and data in the primary image file. Dependent image files can themselves contain lists of additional dependent image files. In the case of the local enclave system of FIG. 9, primary and dependent images can be archived on any accessible storage device, such as through a locally accessible file system. In the case of the remote enclave system of FIG. 10, the primary image file can be on any storage device accessible to both computer 1010 and computer 1050. If client 1056 requests the creation of an enclave on computer 1010 using the primary image located on computer 1050, the platform remote abstraction and client end 1016 can coordinate to copy the specified primary image file to the 1010 computer.
[0078] CreateEnclave is an example of a method to instantiate an enclave. The CreateEnclave method can be described with the pseudocode:
HANDLE
CreateEnclave (
Jn_ PCWSTR enclavePath,DWORD flEnclaveType, Jn_ DWORD dwFlags,
ln_reads_bytes_ (dwlnfoLength)
PCVOID enclaveinformation, ln_ DWORD dwInfoLength,
Petition 870190061562, of 7/2/2019, p. 46/142
36/101 _Out_opt_P DWORD enclaveError)
[0079] The pseudocode used to describe the methods in this document can use several pseudocode conventions for the definition of API interfaces. For example, function parameters, such as the enclavePath above, can be decorated with "_ln_" or "_Out_" to indicate that a parameter is an input or output parameter, respectively. “_Out_opt_” can indicate an optional output parameter. Words with all capital letters can indicate a data type. HANDLE can be a number, such as a 32-bit number, used to indirectly refer to something. For example, the CreateEnclave method above returns a HANDLE for the caller of CreateEnclave, and that HANDLE can be a handle to the enclave that was created; PCWSTR can be a pointer to a certain type of text string; DWORD can be an unassigned 32-bit quantity; PCVOID can be a pointer to data of a non-specific type; BOOL can be a binary value.
[0080] CreateEnclave can allow a client, such as client 916, to create an enclave and load the primary image within the enclave. Any enclave configuration information in this image can be associated with the instantiated enclave. CreateEnclave can include the following parameters:
IpEnclaveName: you can specify the path to the primary image of the enclave, which in implementations can be some other type of identifier to identify the code and / or data of the primary image of the enclave, such as a handle for an open file, an identifier uniform resource (URI), or an identifier that is used in an external search. For example, a globally unique identifier (GUID) can be used as a key in
Petition 870190061562, of 7/2/2019, p. 47/142
37/101 a database of primary images. In other implementations, this parameter can identify a memory region that contains the primary image of the enclave.
flEnclaveType: you can specify the type of enclave to be created (in the case where an enclave image supports several types). It can be defined as DEFAULT in the case where the binary supports only one enclave or where the developer has explicitly set it as default. dwFiags: you can specify one or more predetermined actions to be taken when creating the enclaves and loading the primary enclave image, enclaveinformation: it can be an optional input parameter for configuring the enclave runtime.
IpEnclaveError: you can specify an optional parameter to return an architecture-specific error code.
[0081] Upon successful completion, CreateEnclave can resume a handle for the enclave. After an error, NULL can be returned. Other identifiers (GUID, URI, etc.) can also be returned without departing from the scope of this disclosure. For the sake of simplicity, this specification will describe APIs using a handle. The enclave creation may fail, for example, due to a lack of enclave memory, lack of support for the specific enclave type on the abstraction platform or on the native platform, or the creation may fail due to explicit configuration policies that prevent an enclave of a specific type is executed in the system.
[0082] Implementations of CreateEnclave and other API methods described below can exclude one or more of the described method parameters. For example, with respect to CreateEnclave, IpEnclaveName, flEnclaveType, dwFiags, and enclaveinformation can
Petition 870190061562, of 7/2/2019, p. 48/142
38/101 be excluded, using a specific predetermined value for that particular API. The IpEnclaveError argument can also be excluded from the API, and alternative methods for checking errors in the API call can optionally be implemented.
[0083] CreateEnclave can be responsible for loading all dependent modules as specified in the primary enclave image. The primary enclave image can be a portable execution file (PE) that specifies other binary image files on which the binary image depends. CreateEnclave can also perform the native platform-specific initialization, such as finalizing measurements for certification, allocating structures for transport layer security (TLS) and / or other key agreements and communication protocols, etc. The enclave abstraction protocol interfaces 920, 922 (including methods, for example, for data locking and certification) may be operational once the enclave initialization has been completed.
[0084] TerminateEnclave is an example of a method for completing an enclave:
VOID
TerminateEnclave (
Jn_ HANDLE hEnclave [0085] TerminateEnclave can be used to destroy an enclave. In implementations, the destruction of an enclave may include the imposition that all enclave strings return to the host or terminate, and / or the release of memory associated with the enclave. Calling TerminateEnclave to a running enclave can terminate it and free all resources associated with the enclave.
[0086] The enclave abstraction platform 912 can include execution control transfer primitives that can be
Petition 870190061562, of 7/2/2019, p. 49/142
39/101 used, for example, to transfer control between an enclave and its client. Execution control transfer primitives can enable communication between enclave 914 and client 916 by starting code execution at an entry point in the other component. Execution control transfer primitives allow data to pass into and out of enclaves by allowing parameters to be associated with the control transfer request; the parameters can specify individual data items (the parameters are themselves communicated) or the parameters can be pointers to memory areas (buffers pointed to by the parameters that are communicated). These primitives can enable transfer of control despite limitations in directly calling or jumping between enclave 914 and client 916 due to security restrictions on the enclave container.
[0087] For calling in an enclave, the 924 interface can include mechanisms to allow a 916 client to call a 914 enclave through the 920 interface. For example, the 924 interface can include the GetProcAddress and CallEnclave methods:
typedef PVOID (* ENCPROC) (PVOID);
ENCPROC getProcAddress (
Jn_ HMODULE hEnclave, _ln_ LPCTSTR IpProcName )BOOL CallEnclaveln (Jn_ ENCPROC pCallin, Jn_ PVOID pParameter, _Out_ PVOID pReturn
Petition 870190061562, of 7/2/2019, p. 50/142
40/101 [0088] An enclave client, such as client 916, can call into an enclave, such as enclave 914, using the pointer function returned by GetProcAddress (). The IpProcName parameter can correspond to the function exported in the primary enclave image. For example:
// Call Callin function for enclave.
ENCPROC pCallin “· (ENCPROC) GetProcAddress (nEnclave,“ CallinExample ”);
PVOID pParameter; // Pointer to memory
If (NULL to pCallin) {
Ca! IEnclaveln (pCallin, pParameter);
} [0089] In other GetProcAddress modalities, IpProcName can be another identifier of the specific exported function, such as a number, such as a selection from an enumeration of entry points exported from an enclave image, or another identifier not. corresponding to the function. Other modalities of CallEnclaveln can additionally take an input parameter specifying the enclave in which to call, for example, the handle returned from CreateEnclave.
[0090] When calling in an enclave, a segment in the customer process can be suspended and an enclave segment (with a separate segment ID) can be used to serve the requested call. The enclave code, running in the enclave segment, can then have access to the memory that was previously available to the enclave client before the enclave call. For example, the client can put the data in the buffer pointed by the pParameter before calling the CallEnclaveln abstraction method, and then the enclave can have access to the buffer pointed by
Petition 870190061562, of 7/2/2019, p. 51/142
41/101 pParameter while serving the call on request. After calling out, the original calling (customer) segment can be used to serve the outgoing call. A recess may be supported (for example, a call out to a host may call into an enclave again).
[0091] To call out of an enclave, the 922 interface can include methods related to the CallEnclaveln method above which allows an 914 enclave to call out to the 916 enclave client. For example, the 914 enclave can call out to any function in the hosting process of a particular type, for example, the ENCPROC function type. The pointer function for it can be passed using the call in parameters for the enclave.
BOOL
CallEnclaveOut (
Jn_ ENCPROC pCallout,
Jn_ PVOID pParameter, _Out__ PVOID pReturn)
// Call out to the function in the hosting process ENCPROC pCallout = (ENCPROC) OxFOO; // address for some function in the hosting
PVOID pParameter = // Pointer to the memory CallEnclaveOut (pCallout, pSharedMemory);
The 920 interface can include the entry points registered as the “CallinExample” function above, and the 926 interface can include the entry points registered as the “Callout” functions above. For example, in the case where the primary enclave image is in a portable execution image format (PE), the function entry points in the image can be listed as “exported” entry points, and each of these entry points exported can include a name
Petition 870190061562, of 7/2/2019, p. 52/142
42/101 textual, such as “CallinExample”, to identify and differentiate the entry points in this PE enclave image; in other implementations function entry points can be marked with additional metadata, such as a bit that indicates that the function can be an entry point for the enclave. In the example above to call out of the enclave, the address of the callout function is given as OxFOO and is just an example. The actual address of a callout function can be determined in a variety of ways. For example, a callout function address within a client can be passed into the enclave as a parameter to a call-in function. In another example, the address of a callout function can be registered by the customer using a function such as RegisterCallOut:
BOOL RegisterCallOut (_ln_ ENCPROC pCallout,
Jn_ LPCTSTR IpProcName)
The code inside the enclave can obtain the address of the callout function when calling a complementary function such as GetCallOut:
BOOL GetCallOut (_Out_ ENCPROC * pCallout, _ln_ LPCTSTR IpProcName) [0092] In other modalities, the CallEnclaveln and
CallEnclaveOut can actually be the same method. For example, a single CallEnclave method can be used to call in and call out of an enclave. In situations where the 916 enclave client is also the enclave, the call out of the 914 enclave to the 916 client will also be a call into an enclave.
[0093] The 912 abstraction platform can provide primitives to block data for an enclave. For example, interface 922 can provide services for the 914 enclave, such as blocking and
Petition 870190061562, of 7/2/2019, p. 53/142
43/101 unlocking data for an enclave identity, As explained above, an enclave can have multiple nested identities, and data can be locked for any of those identities. When data is blocked for an identity that corresponds to a set of possible enclave instantiations, the blocked data can be unlocked by any of the corresponding enclave instantiations. For example:
struct SEALING ... POLICY {
ENCLAVE J D_TYPE enclaveldType;
};
[0094] For each value of enclaveldType, the enclave will block for a mapped ID. Possible types of enclave identity (and enclaveldType values) include:
ENCLAVE_EXACTHASH
ENCLAVEJNSTANCEHASH: // block using
MRENCLAVE for SGX,
IMAGE HASH to VSM
ENCLAVEJMAGEIDS: // not supported in SGX, will use IMAGE IDS for VSM
ENCLAVE J = AMILYID: // will use PRODUCTID for SGX, FAMILY ID for VSM
ENCLAVE__AUTHORID: // will use MRSIGNER for SGX, AUTHOR ID for VSM [0095] The platform can also apply an additional debug configuration (elaborate and at run time) for the blocking policy. For different debugging policies, different lock keys can be used. For example, release and debug configurations can use different lock keys.
DWORD
Petition 870190061562, of 7/2/2019, p. 54/142
44/101
EndaveSeal (Jn_ SEALING__POLICY sealingPolicy, JnjOads _m bytes._ppt _. (DwPlaintextSize) LPCVOID pPIaintext, Jn_ DWORD dwPlaintextSize,
Jn_reads_bytesj3ptJdwAuthdataSize) LPCVOID pAuthdata, Jn_ DWORD dwAuthdataSize, _Out_writes_bytes_to_ (dwSealedtextSize) LPCVOID pSealedtext, Jnout_ DWORD * dwSealedtextSize
DWORD
EnclaveUnseal (__ln_reads__bytes__opt __ (dwSealedtextSize) LPCVOID pSealedtext, DWORD Jn_ dwSealedtextSize, _ln_reads_bytes_opt_ (dwAuthdataSize) LPCVOID pAuthdata, DWORD Jn_ dwAuthdataSize, _Out_writes_bytesJo_ (dwPlaintextSize) LPCVOID pPIaintext, DWORD Jnout_ * dwPlaintextSize [0096] Abstraction platform 912 can provide primitive for certification , such as for the production of quotas and certification reports, and for quotas and verification reports, for example:
DWORD
CreateReport (Jnjeads_bytes_opt_ (dwTargetlnfoSize) PCVOID pTargertlnfo, Jn_ DWORD dwTargetlnfoSize, __ln_reads__bytes__opt __ (dwAuthData) PCVOID pAuthData, Jn_DWORD, * dn
Petition 870190061562, of 7/2/2019, p. 55/142
45/101
Jnout_ PDWORD pReportSize,
JDut_opt_ PDWORD IpEnclaveError)
DWORD
VerifyReportf
Jn_reads__bytes_ (dwReportSize) PCVOID pReport,
Jn_ DWORD dwReportSize,, „. 0ut_, ppt ___ LPDWORD IpEnclaveError)
[0097] VerifyReport () can be used by an enclave to affirm the integrity of a report and that the report was generated by an enclave on the same machine.
DWORD CreateQuote (
Jn___ GUID quoteType,
Jn_ DWORD authDataSize, _ln_reads_bytes_opt_ (authDataSize) const BYTE * authdata, _Out__ DWORD * quoteSize, _Outptr_result_bytebuffer_opt _ (* quoteSize) BYTE * quote [0098] In CreateQuote, a quoteType can be used as a source for a supplier the specific quota. In CreateQuote, authData can be a pointer to the data that is created by, and in a format defined by, the caller of CreateQuote. Note that authData does not need to be understood by the 912 abstraction platform. AuthData can be packaged in the resulting dimension. Quota providers can be expected to offer this.
DWORD VerifyQuote (
Jn_ DWORD quoteSize,
Jnjeads_bytes_ (quoteSize) const BYTE * quote,
Petition 870190061562, of 7/2/2019, p. 56/142
46/101 _Out_ DWORD * reportSize, _Outptr__result_bytebuffer__alL (* reportSize) BYTE ** report [0099] In addition to the enclave primitives described above, an enclave abstraction platform can provide: memory management (for example, to allocate and free memory , such as a memory restricted to an enclave or a memory that is shared between the enclave and its client); exception handling (for example, to handle an error, or exceptions, that occur while executing the enclave code); segment synchronization; and encryption functions (for example, encryption, scrambling functions, and signing).
[0100] The techniques described above can be implemented in one or more computer devices or environments, as described below. FIG. 11 describes an example of a general purpose computing environment, for example, which can incorporate one or more trusted hardware 172, trusted platform 736, or computers 810, 910, 1010, and 1050, in which some of the techniques described in this document may be incorporated. The computing system environment 1102 is only an example of a suitable computing environment and is not intended to suggest any limitations on the scope of use or functionality of the subject currently disclosed. Nor should computing system 1102 be interpreted as having any dependency or requirement related to any or a combination of the components illustrated in the operating environment example 1102. In some embodiments, the various computing elements described may include configured circuits. to instantiate specific aspects of this disclosure. For example, the term circuit used in the disclosure may include specialized hardware components
Petition 870190061562, of 7/2/2019, p. 57/142
47/101 configured to perform function (s) by firmware or keys. In other example modalities, the term circuit can include a general purpose processing unit, a memory, etc., configured by software instructions that incorporate an operational logic to perform a function (s). In example modalities where the circuit includes a combination of hardware and software, an implementer can write the source code incorporating logic and the source code can be compiled into machine-readable code that can be processed by the general purpose processing unit. Once a technology expert can appreciate that the state of the art has evolved to a point where there is little difference between hardware, software, or a hardware / software combination, selecting hardware versus software to perform specific functions is a design choice left to an implementer. More specifically, a technology expert can appreciate that a software process can be transformed into an equivalent hardware structure, and the hardware structure itself can be transformed into an equivalent software process. In this way, the selection of a hardware implementation versus a software implementation is a design choice and is left to the implementer.
[0101] Computer 1102, which can include any of a mobile device or smart phone, tablet, laptop, desktop computer, or a collection of networked devices, cloud computing resources, etc., usually includes a variety computer-readable media. The computer-readable medium can be any available medium that can be accessed by computer 1102 and includes both the volatile and the non-volatile medium, the removable and non-removable medium. The 1122 memory system includes a computer-readable storage medium in the form of non-memory
Petition 870190061562, of 7/2/2019, p. 58/142
48/101 volatile and / or volatile such as read-only memory (ROM) 1123 and random access memory (RAM) 1160. A basic 1124 input / output system (BIOS), containing the basic routines that help transfer the information between elements within computer 1102, such as during start-up, is normally stored in ROM 1123. RAM 1160 typically contains data and / or program modules that are immediately accessible to and / or are currently being operated by a processing unit 1159. By way of example, and not by way of limitation, FIG. 11 illustrates a hypervisor 1130, an operating system (OS) 1125, application programs 1126, other program modules 1127, including an enclave client 1165, and an enclave 1128.
[0102] Computer 1102 may also include other volatile / non-volatile, removable / non-removable computer storage media. By way of example only, FIG. 11 illustrates a hard disk drive 1138 that reads from, or writes to, a removable non-volatile magnetic disk 1154, and an optical disk drive 1104 that reads from, or writes to, a removable non-volatile optical disk 1153 such as a CD ROM or other optical media. Other volatile / non-volatile, removable / non-removable computer storage media that can be used in the sample operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile discs, digital video tapes , Solid state RAM, solid state ROM, and the like. The 1138 hard drive is usually connected to a 1121 system bus via a non-removable memory interface such as the 1134 interface, and the 1139 magnetic disk drive and the optical disc drive 1104 are usually connected to the system bus 1121 via a removable memory interface, such as interfaces 1135 or 1136.
Petition 870190061562, of 7/2/2019, p. 59/142
49/101 [0103] The units and their associated computer storage media discussed above and illustrated in FIG. 11 provide storage of computer-readable instructions, data structures, program modules and other data for computer 1102. In FIG. 11, for example, hard drive 1138 is illustrated as storing an 1158 operating system, 1157 application programs, other 1156 program modules, such as enclave client applications and enclave binary files, and 1155 program data. Note that these components can either be the same as or different from the 1125 operating system, 1126 application programs, other 1127 program modules, and 1128 program data. The 1158 operating system, 1157 application programs, other modules program number 1156, and program data 1155 has been given different numbers here to illustrate that, at the very least, they are different copies. A user can enter commands and information on computer 1102 through input devices such as an 1151 keyboard and a 1152 pointing device, commonly referred to as a mouse, a trackball or a touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, retinal scanner, or the like. These and other input devices are often connected to the processing unit 1159 via a user input interface 1136 which is coupled to the system bus 1121, but can be connected by another interface and bus structures, such as a parallel port, a game port, or a universal serial bus (USB). A 1142 monitor or other type of display device is also connected to the 1121 system bus via an interface, such as an 1132 video interface. In addition to the monitor, computers can also include other output devices
Petition 870190061562, of 7/2/2019, p. 60/142
50/101 peripherals such as speakers 1144 and printer 1143, which can be connected via an 1133 peripheral output interface.
[0104] Computer 1102 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 1146. Remote computer 1146 can be a personal computer, a server, a router, a network PC , a peer device, or other common network node, and typically includes many or all of the elements described above in relation to computer 1102, although only one memory storage device 1147 has been illustrated in FIG. 11. The logical connections described in FIG. 11 include a local area network (LAN) 1145 and an extended area network (WAN) 1149, but can also include other networks. Such network environments are common in offices, corporate computer networks, intranets, the Internet, and cloud computing resources.
[0105] When used in a LAN network environment, computer 1102 is connected to LAN 1145 through an adapter or 1137 network interface. When used in a WAN network environment, computer 1102 typically includes a 1105 modem or other means to establish communications over WAN 1149, such as the Internet. Modem 1105, which can be internal or external, can be connected to the system bus 1121 via an 1136 user input interface, or by another appropriate mechanism. In a networked environment, described program modules relating to computer 1102, or portions thereof, can be stored on remote memory storage devices. By way of example, and not by way of limitation, FIG. 11 illustrates 1148 remote application programs as residing on an 1147 memory device. It will be appreciated that the network connections shown are
Petition 870190061562, of 7/2/2019, p. 61/142
51/101 copies and other means to establish a communication link between computers can be used.
[0106] FIG. 12 describes an example of a flowchart of a method 1200 of abstraction from a native enclave platform. An abstraction platform, such as 912 in FIG. 9, you can receive a request for an enclave platform in box 1202. The request may come from an enclave client, such as client 914, or an enclave, such as enclave 916.
[0107] A request from an enclave may be a request to execute an abstraction platform primitive and may include, for example, a request to: create a quota or certification report for an enclave; block data for the enclave; calling a function on the client from an enclave (calling the client); read a monotonic counter (provide the current value of a monotonic counter); provide a reliable time measurement; and allocating memory that can be shared between an enclave and its client (for example, allowing a pointer to share memory to be passed as a parameter when calling into or out of an enclave). In some embodiments, the total virtual memory space of an enclave client can be shared with (and accessible from) the enclave, such that a request to allocate shared memory can be implemented as a request to allocate memory for the enclave client. In some embodiments, shared memory allocation methods are available to both an enclave and its client.
[0108] A request from an enclave client can be a request to execute an abstraction platform primitive and can include, for example, a request to: instantiate an enclave; check an enclave certification report; call a function within an enclave (call in an enclave); and allocate
Petition 870190061562, of 7/2/2019, p. 62/142
52/101 memory that can be shared between the enclave and your client.
[0109] An abstraction platform request can be translated into a native platform request in operations 12041208. The parameters included or implied in the received request can be converted into an optional step 1204 if it is determined, for example, that the data format of the parameter in the original request is not the same as the data format for the parameter on the native platform. For example, if a request from an enclave or customer includes a parameter derived from an abstraction format certification report, such as an enclave abstraction identity, it will be converted to a parameter used in a format certification report native, such as a native enclave identity.
[0110] If it is determined that the calling convention of the native platform and the request received differ, the calling convention can be converted into an optional step 1206. A calling convention can be converted, for example, by reordering parameters in a stack calls, by moving parameters between processor records and a call stack, and converting between error condition communication methods such as returning an error value and calling an exceptional handler.
[0111] In some modalities, the native platform can be identical to the abstraction platform for some requests, in which case the conversion operations of boxes 1204 and 1206 can be ignored.
[0112] In box 1208, the converted request is sent to the native platform to make the request be executed by the native platform. For example, in the event that the native platform conforms to Intel's Software Guard Extensions (SGX) enclave architecture, the native platform may include
Petition 870190061562, of 7/2/2019, p. 63/142
53/101 processor for enclaves. In this case, sending the request in box 1208 may include executing one or more processor instructions for enclaves. In another example, the native platform can conform to Microsoft's Virtual Secure Mode (VSM) enclave architecture, which may include a hypervisor with hyper-calls to the enclave. A hypercall is a software trap for hypervisor codes, and a hypercall can cause the processor context to change to a context in which privileged operations can be allowed. In this VSM example, sending the request at box 1208 can include making hyper calls to the hypervisor and / or another mechanism to change the execution context to a context where privileged operations can be allowed.
[0113] Sending a request to a native platform here generally means executing the request using the resources of the native platform. The operation of sending the request to the native platform 1208 can involve multiple operations with the native platform, and can vary depending on the requested operation (or primitive), such as the creation of an enclave, certification, data blocking, transfer of control, or use of monotonic counters and reliable time.
[0114] The CreateEnclave primitive can be used to instantiate an enclave. A CreateEnclave request to instantiate an enclave can cause the abstraction platform to create a secure container (for example, when allocating some memory and establishing security or an isolation boundary for that memory), copy the enclave code into that memory secure container (for example, from an enclave image), and configure or enable entry points in the enclave code (for example, according to an entry point metadata in an enclave image).
Petition 870190061562, of 7/2/2019, p. 64/142
54/101 [0115] Sending a CreateEnclave request to a native platform with an enclave-enabled hypervisor (a hypervisor that provides enclave management functions, such as VSM), can include allocating memory and making hyper calls to define processor page tables for memory in a way that prevents codes external to the enclave container from accessing that memory. Enclave creation hyperlinks from the abstraction platform can also cause the hypervisor to define configuration information for transferring control within the enclave at designated entry points. Subsequently, a code external to the secure container can make control transfer hyper calls for the transfer execution at the designated entry points inside the secure container.
[0116] Sending a CreateEnclave request to a native platform with an enclave-enabled processor (a processor with processor instructions for enclave management, such as SGX), can include the abstraction platform by executing an instruction such as ECREATE for inform the CPU that a certain area of memory should be created as a secure enclave container, and execute an instruction such as EADD to add data pages to that enclave container. Special processor instructions can also be used to create special pages in memory for designating entry points into the enclave for transferring control within the enclave. Subsequently, a code external to the secure container can execute an instruction such as EENTER that specifies one of the entry points designated for the transfer execution control for that entry point of the enclave.
[0117] The CreateReport primitive can be used to create a
Petition 870190061562, of 7/2/2019, p. 65/142
55/101 certification report. A CreateReport request to create a certification report for an enclave can be performed by an abstraction layer as explained above with respect to FIGS. 5 and
7. With an enclave-enabled hypervisor, an abstraction layer can send the request to the native platform by performing a hyper-call that changes the execution state to, for example, a security monitor context that has access to a secret key such as such as PrivAK 726 of FIG. 7 that can be used to sign reports. This secret key may only be available for the security monitor context if the computer is booted in a healthy configuration as verified with a TCG log based on a TPM. The security monitor can tag the report data with an identity from the enclave being certified.
[0118] With an enclave-enabled processor, a CreateReport request can be sent to the native platform when executing an instruction, such as EREPORT, which generates a report and sends it to a special enclave that will have access to a private key to sign the reports.
[0119] The EnclaveSeal primitive can be used to block data for an enclave. Blocking data for an enclave encodes the data in a manner or with a key that is associated with the enclave. An EnclaveSeal request can be a request to block data located within an enclave, such as all or part of the state of the enclave, for the enclave that uses a blocking policy. The locking policy, like SEALING ,,, POLICY above, can specify a type of enclave identity that indicates which enclaves should be able to unlock the data. Blocking processes themselves can use an encryption key associated with the enclave identity specified in the blocking policy.
Petition 870190061562, of 7/2/2019, p. 66/142
56/101
Thereafter, a new enclave instantiation may be able to unlock the data if the new enclave identity value in the specified identity type is the same as the lock enclave identity value in the specified identity type.
[0120] Data blocking allows sensitive or secret enclave data to be safely copied to insecure storage, such as a memory outside the enclave's secure container or to persistent storage such as a hard drive. When the blocked data is enclave state data, blocking allows an enclave to be reset to a previous state, and allows a secure enclave operation to be interrupted and later continued on to another enclave.
[0121] To redefine an enclave state, first an enclave state is saved by blocking its state for an enclave. Blocking can be done by encrypting the state data with a key associated with the enclave. Later, perhaps after the enclave state has been changed, the blocked state data can be unlocked for the same enclave by decoding the blocked data and then replacing a current state of the enclave with the decoded data (for example, when copying the decoded data to the secure enclave container).
[0122] To interrupt a safe operation and continue it in another enclave, the safe operation starts when executing an operation comprising several processor instructions in a first enclave. When the first enclave is interrupted, the state of that enclave can be blocked to an enclave identity specified in the blocking policy, and the blocked data can then be saved to insecure storage, such as local or based persistent storage. a cloud. The first enclave can then be (optionally) completed or initiated
Petition 870190061562, of 7/2/2019, p. 67/142
57/101 other enclave operations. A second enclave can be instantiated or adapted to continue the interrupted operation by unlocking the locked state data in the second enclave. The interrupted operation can be continued in the second enclave from the point where the first enclave left it.
[0123] With an enclave-enabled hypervisor, an abstraction layer can send an EnclaveSeal request to the native platform when performing a hyper-call. The hypercall can change the execution state to a context, for example, a security monitor context, which will have access to a secret lock key associated with the enclave that can be used to lock or unlock the data. The lock key can be derived from a combination of an enclave identity and a secret platform key available only to the security monitor. This platform key can only be available to the security monitor when the machine is rebooted to a healthy configuration, and the boot configuration is verified with a TPM-based TCG log. In this enclave-enabled hypervisor mode, the enclave code never has access to the lock key.
[0124] With an enclave-enabled processor, the EnclaveSeal request can be sent to the native platform when executing an instruction, such as EGETKEY, to acquire an encryption key. This algorithm can generate a lock key that is unique to the enclave. The lock key can be derived from an enclave identity and a secret built into the processor. The code inside the enclave can then encrypt the data with the lock key. Data can be blocked by encryption with the lock key, for example, by code inside an enclave, by an abstraction platform, or by a native platform. EnclaveUseal can similarly use
Petition 870190061562, of 7/2/2019, p. 68/142
58/101 to EGETKEY to generate the unlock key.
[0125] A request for transfer of control can be a request to transfer control of processor execution from instructions inside the enclave to an entry point outside the enclave (for example, CallEnclaveOut), or the other way around , from instructions outside the enclave to an entry point inside the enclave (for example, CailEnclaveln). This can be done, for example, by a secure database operation. After instantiating an enclave database, an enclave client can request that the enclave perform a specific operation, such as querying the database when using the primitive CailEnclaveln to transfer control to an entry point inside the database of the enclave that will perform the query. After the enclave finishes the query, the result of the query can be returned (possibly after encrypting the result) to the client with the CallEnclaveOut primitive to transfer control back to the client at an entry point on the client that can receive the query result. The primitives CailEnclaveln and CallEnclaveOut can take a pointer to a memory buffer that can be shared between an enclave and its client (the buffer can be readable, writable, and / or executable by both the enclave and its client).
[0126] With an enclave-enabled hypervisor, an abstraction layer can send a CailEnclaveln request to the native platform when performing a hypercall. The hypercall can change the execution state to a context, for example, a security monitor context, which will save the CPU records, restore a set of previously saved enclave CPU registry values (possibly from the memory of enclave), change the page table setting to allow access to memory
Petition 870190061562, of 7/2/2019, p. 69/142
59/101 protected from the enclave, and invoke a function entry point inside the enclave. Similarly, when an abstraction platform receives a CallEnclaveOut request, the request can be sent to the native platform via a hyper call that will save the enclave CPU records (possibly saving the enclave memory) and restore the records from CPUs previously saved for an enclave client, change the page table setting to prevent access to the enclave memory, and transfer the processor protocol to an entry point on the enclave client outside the enclave.
[0127] With an enclave-enabled processor, a CallEnclaveln request can be sent to the native platform when executing an instruction, such as EENTER, which can cause the CPU to restore a set of enclave CPU records (possibly from enclave memory) and invoke a function (transfer of control to an entry point) inside the enclave. A CallEnclaveOut primitive can execute an instruction, such as EEXIT, which can transfer control to instructions outside the enclave and / or cause a failure to transfer control outside the enclave.
[0128] A monotonic counter has a variety of uses. For example, an enclave may want to restrict how far back its state can be reversed. Monotonic counters can be used, for example, as a nonce to ensure the timeliness of messages, as discussed above in relation to FIG. 4. Monotonic counters generally have the ability to be read, and to be incremented, but they cannot be decremented. To restrict a return or reversal of the enclave state, the code inside an enclave can increment an associated monotonic counter, and then save the counter value together with the internal state of the enclave.
Petition 870190061562, of 7/2/2019, p. 70/142
60/101 enclave. The status and value of the counter can be saved, for example, with the EnclaveSeal primitive. Later, when restoring the enclave state, for example with the use of the EnclaveUnseal primitive, the code inside the enclave can read the current value of the monotonic counter and compare it to the counter value with the state unlocked. If the value of the counter with the unlocked state is less than the current value of the counter, the enclave can prevent the use of the unlocked state.
[0129] With an enclave-enabled hypervisor, an abstraction layer can send a request to the native platform to read or increment a monotonic counter when performing a hyper call that is exposed to the enclave. When a hypercall for reading or incrementing the counter is invoked, the processor will change the execution state to a context, such as a security monitor, which will verify the identity of the enclave performing the hypercall, and then read from or increment, respectively, the corresponding monotonic counter stored in, for example, a non-volatile storage such as a TPM chip. Alternatively, the security monitor can read or increment a counter stored on a remote trusted server or on a set of remote trusted servers, by establishing a secure communication channel with that server and asking it to read or increment a specific monotonic counter. . The remote trusted server or servers can keep the counter inside an enclave to isolate it from the rest of the code on the host computer.
[0130] With an enclave-enabled processor, a request can be sent to the native platform when executing an instruction. With such a processor, monotonic counter primitives can be implemented by reading or incrementing a counter in a non-volatile memory storage on a chip in the
Petition 870190061562, of 7/2/2019, p. 71/142
61/101 computer motherboard. Alternatively, these primitives can also be implemented using a trusted remote server as well as the enclave-enabled hypervisor.
[0131] FIG. 13 describes an example of a flow chart for a 1300 method of abstraction from a native enclave platform. An enclave abstraction platform can receive a request from an enclave or an enclave client in box 1302. In box 1304, the abstraction platform can determine whether the native platform includes enclave processor instructions, for example, when determine if the native platform conforms to SGX. If this is true, the enclave processor instructions are executed in box 1306. In box 1308, the abstraction platform can determine whether the native platform includes enclave hypercalls, for example, by determining whether the native platform conforms to VSM. If this is true, the native platform performs the enclave hyper-calls. The results from executing the enclave instructions or calling the enclave hypercalls are cleared in box 1312. Clearing may include, for example, converting the output parameters or exception handling of the enclave processor instructions or hyperlink calls. enclave for an abstraction layer interface format or protocol. The converted output parameters are then returned to the original requester (enclave or customer) in box 1314.
ABSTRACT ENCLAVE IDENTITY [0132] FIG. 14 describes an example of binary enclave images used to instantiate an enclave. An enclave can be instantiated by creating a secure container, such as the 1490 enclave container, and by copying portions of one or more enclave images into the Container Interior. Enclave container 1490 may have been created by reference to primary enclave image 1410. An image
Petition 870190061562, of 7/2/2019, p. 72/142
62/101 Primary may include references to other dependent enclave images. In this example, primary image 1410 includes Dependence 1 and Dependence 2 as references to dependent enclave images 1420 and 1450, respectively. Image 1420 includes additional dependencies on images 1430 and 1440, while image 1450 depends on image 1460. Once all of these images (or portions thereof) have been copied into the 1490 container, the resulting enclave may include external images to platform 1402, which may include code and data that are unique or specific to the instantiated enclave, images from abstraction platform 1404, and images from native platform 1406.
[0133] Each enclave image, such as primary image 1410, may include IDs, dependencies, codes, data, and a signature from the image's author. In image example 1410, two IDs 1410.1 and 1410.2 are included. These IDs can be UUIDs that specify, for example, an abstract identity value corresponding to an ImagelD, FamilylD, or AuthorlD value that, individually or collectively, can be used to identify any enclave instantiated with that enclave image. As described, image 1410 has two IDs, but fewer or more IDs are doable. The code in image 1410 can be binary instructions executable by the processor of the computer hosting the 1490 enclave container. The data in image 1410 can be used by any code loaded in the 1490 container. Image 1410 can also include a Sig 1410 signature to guarantee the integrity of any or all other content in the image, such as IDs, dependency references, code and data. Other images 1420 - 1460 may similarly contain IDs, dependency references, code, data and signatures.
[0134] A dependency indicator, such as Dependence 1 and Dependence 2 in image 1410, Dependence 1 and Dependence 2 from
Petition 870190061562, of 7/2/2019, p. 73/142
63/101 image 1420, Dependence 1 of image 1450, can be specified in a variety of ways. If 1410-1460 images are stored in a computer system memory, a dependency indicator can simply be an address in memory. If the enclave images are files on a file system, the references can be the names of the files. In some embodiments, references can be a logical identifier. A logical identifier can be a unique number, such as a UUID, or it can be another piece of data, such as a text string, that otherwise identifies a dependency image. For example, a text string can indicate an author of a dependent binary image, font, product name, product family, and / or version number. A logical identifier includes a location on the Internet or the web, as well as a location from which a copy of a dependent binary can be retrieved.
[0135] In some embodiments, an enclave image file can be found by looking for a dependency indicator, such as a logical identifier, in an enclave image record to find a pointer to the current version or a local copy of the referenced enclave image. In some cases, a reliable service can be used to resolve a dependency indicator in identifying a particular enclave image or image location.
[0136] In some embodiments, a dependency indicator can be a cryptographically secure identifier, such as a cryptographic scramble of the intended dependent enclave binary image. Such scrambling can include all of the dependent torque, or just a portion of it. The portion of the dependent binary included in a dependency indicator may have included abstract identity values, such as ID 1410.1 or ID
Petition 870190061562, of 7/2/2019, p. 74/142
64/101
1410.2, and can be abstract identity values. A resolution service for a cryptographically secure identifier may not need to be as reliable as with a logical identifier because the entity that determines the enclave dependencies may be able to verify that the correct dependent image has been found when computing the shuffling of the dependent binary itself.
[0137] FIG. 15 describes an example of a flow chart for a 1500 method for performing an enclave operation with an abstract enclave identity. An abstract identity value for an enclave can provide a basis for determining equivalence between two enclaves that have some feature in common, but are not exactly identical. An identity value can be included in a certification report and can be associated with an abstract identity type (such as ExactHash, InstanceHash, ImagelD, FamilylD, or AuthorlD). Two enclaves that are not quite the same have the same abstract identity value for a type of abstract identity. In addition, an identical enclave code instantiated in secure containers on two different native enclave platforms can also have the same abstract identity value. Method 1500 can be executed, for example, by an abstraction platform layer between a native enclave platform and both an enclave and an enclave client.
[0138] In box 1502, an enclave is instantiated from an enclave image, such as the primary enclave image 1410 of FIG. 14. The enclave image can be a primary image that includes the enclave code, data, a list of identities, a list of any dependent enclave files, and a signature. To ensure the integrity of the enclave images, the images can be signed with a private key that can correspond to the author of the enclave image. The list of enclave IDs in the image
Petition 870190061562, of 7/2/2019, p. 75/142
65/101 of enclave can correspond to types of abstract identity such as an ImagelD, a FamilylD, and an AuthorlD, each aiming to collectively identify the enclave image together with other related enclave images. A list of dependent enclave images can refer to other enclave images containing the enclave code on which the code in the primary enclave image depends. A dependent enclave image may or may not be authored by the same author, and some dependent enclave images may generally be associated with an enclave platform (either an abstraction platform or a native platform) rather than being particularly associated with an image primary enclave or with the author of the primary enclave image. The enclave can be instantiated by creating a secure enclave container using any native enclave platform, and by copying all or part of the primary image and any dependent enclave images into the secure container.
[0139] In box 1503, an enclave operation is requested, for example, by an enclave or by an enclave client, together with an enclave identity type. The identity type can specify an abstract identity type, such as an ImagelD or an AuthorlD, and be related to a particular instantiated enclave, but it does not specify the Authorld value for that enclave. The remainder of method 1500 following box 1503 describes operations for performing the operation (such as a certification, a data lock, or the use of a monotonic counter, etc.) with the enclave instantiated using an identity value derived for that type of identity of the instantiated enclave. Identity can be determined using a scramble of a subset of the enclave image (s). Which subset of the enclave image (s) are used as input to the
Petition 870190061562, of 7/2/2019, p. 76/142
66/101 scrambling can be based, in part, on the type of identity you want to use in the enclave operation.
[0140] In box 1504, a portion of the enclave image, called an identity portion in this document, is determined based on the type of identity. The identity portion can include all of, part of, or none of several enclave binary images used to instantiate an enclave in box 1502. The identity portion can include all of, part of, or none of an enclave code contained in enclave image. The identity portion can also include zero, one, or more identity IDs listed in a portion outside the code of the included enclave images. The identity portion may or may not include the enclave data contained in the enclave images. The identity portion can also include any combination of these various parts of the enclave images. For example, a portion of identity can include everything in the code, none of the data, and two or four available identity IDs. In optional box 1506, it is determined which dependent enclave images are to be included in the identity portion, and an identity portion of each included image is determined.
[0141] The identity portion of the dependent images may or may not be the same as the identity portion of a primary enclave image. For example, all code and ImagelD are included in the identity portion of a primary image, while no code and only the FamilylD of a dependent image can be included in the identity portion of the dependent image.
[0142] When the enclave code is included in the identity portion, the portions of the enclave code in the identity portion can be determined by a combination of the identity type and an indication of which dependencies should be included in the identity portion. The type of InstanceHash identity can include, for
Petition 870190061562, of 7/2/2019, p. 77/142
67/101 example, the enclave code in the primary image, but no dependent image, while the ExactHash identity type can include the enclave code in all dependent images that are not considered part of an enclave platform. For example, all dependent enclave images that are not signed with the enclave platform author's private key can be considered as not being part of the enclave platform. Alternatively or in addition, the primary image may include a list of which dependent enclave images should be included or excluded in the identity portion for the InstanceHash or ExactHash identity types.
[0143] Enclave identity IDs, which can be included as metadata in an enclave image, can be included in the identity portion of the enclave image instead of, or in addition to, the enclave code. For example, the identity portion for the ImagelD, FamilylD, and AuthorlD identity types can include a corresponding metadata ID from the enclave image. When identity types are nested or layered, the identity portion for the lower level types can include the ID data for the higher level types. For example, the identity portion for ImagelD may include the ID data for ImagelD, FamilylD, and AuthorlD, while the identity portion for AuthorlD may include only the ID data for AuthorlD.
[0144] Identity types that include enclave code, such as InstanceHash and ExactHash, provide a higher level of assurance, for example, to the enclave customer through certification, that certain enclave codes are running inside an enclave. However, the identity of the enclave will necessarily change when any of the identity portions of the enclave code is changed. For example, if a
Petition 870190061562, of 7/2/2019, p. 78/142
68/101 security fix or other bug is fixed in a new version of an enclave image, the resulting identity value based on the new code will also be changed. By providing a mechanism for certain portions of the enclave code to be excluded from the identity scrambling calculation, the identity of an enclave can be decoupled from changes to the excluded portion of the enclave code. For example, when an author's enclave code depends on the enclave code provided by the enclave platform, the enclave identity can be decoupled from revisions for the dependent platform. [0145] In box 1508, an identity value is determined that can represent an enclave identity instantiated in box 1502. An identity value can be determined by calculating a scramble over the previously determined identity portion of the image or images of the enclave (the identity value is the output of a scramble function where the identity portion is the input to the scramble function). In some modalities, the entry for the scrambling function will be the portions of the original enclave image (s), while in other modalities, the entry for the scrambling function will be the portions of an enclave container after the identity portion of the image has been copied into the container (and possibly the identity portion has been decoded in the case where an original enclave image is encoded).
[0146] In box 1510, the integrity of the resulting identity value can optionally be verified by verifying the integrity of the original enclave image (s). The integrity of an enclave image can be verified with a public key that corresponds to the private key used to sign the enclave image. Such a public / private key pair can be associated, for example, with the author of the enclave image (s), so that the
Petition 870190061562, of 7/2/2019, p. 79/142
69/101 confidence in the resulting identity value can be based on the confidence of the enclave author.
[0147] Finally, in box 1512, an operation related to the instantiated enclave can be performed using the identity value. For example: an instantiated enclave certification report can be generated or verified by an identity type; data can be locked to or unblocked from the enclave instantiated in an identity; and a monotonic counter or a reliable time linked to the instantiated enclave and a type of identity can be used.
[0148] Enclave operations use interactions to enable higher-level types of identity between groups of possible enclave instantiations. Certification for a high level identity type can provide a certification report equivalence for all enclaves with the same high level identity. For example, a certification report for an AuthorlD identity type can be equivalent to a certification report from all enclaves instantiated from a primary image containing the same AuthorlD metadata. Blocked data for a high-level identity type can be unlocked by any enclave with the same high-level identity value. For example, data blocked for an enclave instantiated with the identity type AuthorlD can be unblocked by any other enclave instantiated with the same metadata as AuthorlD in its primary enclave image.
ENCLAVE IDENTITY EQUIVALENCE [0149] FIG. 16 describes an example of an abstract enclave identity-equivalent system. An enclave client 1602 can communicate with a first enclave 1612 instantiated in a secure enclave container on the first native platform 1616 through the abstraction platform 1614, and client 1602 can also
Petition 870190061562, of 7/2/2019, p. 80/142
70/101 communicate with a second enclave 1622 instantiated in a secure enclave container on the second native platform 1626 through the abstraction platform 1624. The first native platform 1616 may or may not reside on the same computer as the second native platform. The 1602 enclave client can reside on the same computer as much as the native platforms, or it can reside on a separate third computer. The first 1616 native platform may not be the same as the second 1626 native platform. For example, the first 1616 native platform may be an older version of the second native platform from the same native platform manufacturer. Alternatively, the first native platform 1616 and the second native platform 1626 can conform to completely different enclave architectures, such as VSM and SGX.
[0150] An enclave customer can safely determine that the enclaves are equivalent by comparing the identity values derived from the certification reports. Enclave client 1602 can securely identify each of the enclaves when receiving separate certification reports from the first 1612 enclave and the second 1622 enclave. An identity value can be included (or derived from) each of these reports certification. If the identity values are the same, enclave client 1602 can be confident that the first enclave 1612 and the second enclave 1622 are equivalent in some sense. The identity values from the certification reports can be abstract identity values corresponding to a particular type of abstract identity (such as ExactHash, InstanceHash, ImagelD, FamilylD, or AuthorlD), or shuffling of such abstract identity values. In this case, equivalence can be determined where the enclaves are not exactly identical. Two enclaves may not be exactly identical, but still determined
Petition 870190061562, of 7/2/2019, p. 81/142
71/101 as being equivalent, for example, where the enclave images loaded into the enclave container are different versions of the same functionality, or the same primary images with different dependent images, or the same enclave images loaded into the enclave containers of different enclave architectures.
[0151] The first 1612 enclave can be considered equivalent, but not identical to the second 1622 enclave for a variety of situations. In a first example, only a subset of the code initially loaded into the enclave container is the same (for example, equivalent for the abstract identity types ExactHash or InstanceHash). In a second example, the author of the enclave code may have included an identical ID in two different enclave binary images, even if the code in the two binary images is different (for example, equivalent for the ImagelD, FamilylD, and identity types) AuthorlD). In a third example, the code in each enclave is completely the same, but is loaded (instantiated) on different native platforms. In this third example, the first native platform 1616 and the second native platform 1626 can be manufactured by different manufacturers and, therefore, the trust of the different certification reports is based on the different certificate authorities (see FIG. 7, element 738) of the different manufacturers. An example where the two native platforms are different is a farm server or cloud computing where the servers allocated for processing the workloads of the first and second enclaves are servers that do not support the same native enclave platform.
[0152] In an alternative modality, the first enclave may be the client of the second enclave, such that boxes 1602 and 1612 are combined. The determination of enclave equivalence in this
Petition 870190061562, of 7/2/2019, p. 82/142
72/101 modality may include the determination, within the first enclave, that an identity value from a certification report from the second enclave is the same as the identity value of the first enclave (at a particular abstract identity level) .
[0153] FIG. 17 describes an example of a flowchart for parallel processing with two equivalent enclaves. The 1700 process can be performed, for example, by a customer from two or more different enclaves. In box 1702, two enclaves are instantiated in different instances of the native platform, for example, as described in FIG. 16. Enclaves can be instantiated by an enclave client by specifying a binary enclave image (such as primary image 1410 in FIG. 14) using a CreateEnclave method on abstraction platforms 1614 and 1624. The enclave binary image specified to instantiate the two enclaves can be the same or different. A certification report for each instantiated enclave is created in box 1704. Certification reports can be created, for example, at the request of the enclave customer or at the request of the enclaves themselves. An entity wishing to prove the equivalence of two enclaves, such as the enclave customer, can obtain copies of both certification reports. The certification reports can optionally be verified in box 1706. For example, the Integrity of the report can be verified by verifying the certification signature with an endorsement certificate (as in FIG. 7, element 728) of the native platform that produces the certification report. In addition, the endorsement certificate can be verified with the public key of the manufacturer of the native platform (as in FIG. 7, element 732). The identity values (or their shuffling) can be extracted from each certification report in box 1708, and the equivalence of the two enclaves can be determined by verifying that the identity values
Petition 870190061562, of 7/2/2019, p. 83/142
73/101 extracted are the same for each enclave. These identity values can be abstract identity values (or shuffling them) associated with an identity type.
[0154] Once an enclave client has proven the equivalence of the two enclave instantiations from operations in boxes 1708 and 1710, the two enclaves can be used interchangeably, according to the type of equivalence shown. Boxes 1712 - 1720 describe an example of a method of using equivalent enclaves for using two equivalent enclaves, instantiated, in a parallel processing mode. In boxes 1712 and 1716, a portion of an input data set, such as a portion of a database or a portion of a digital image file, is copied to the first and second enclaves. The portion of the copied data set can be identical or different depending on the processing task at hand. A processing operation can be performed safely in parallel by partially executing, simultaneously, the operation on the first enclave in box 1714 and by partially executing the operation on the second enclave in box 1718. The operation can be, for example, searching the database or perform an image processing operation. The first enclave can search the first half of the database or perform an image processing operation on the first half of the image, while the second enclave can search the second half of the database or perform an image processing operation on the second half of image. Finally, in box 1720, the results of parallel processing in the first and second enclaves can be combined, for example, by combining the two classified halves of the database, or by putting the two halves of the image together again.
[0155] FIG. 18 describes an example flow chart for the
Petition 870190061562, of 7/2/2019, p. 84/142
74/101 series processing with two equivalent enclaves. As described in FIG. 18, an enclave operation, such as a database operation or an image processing operation, is done safely in two sequential parts in two separate enclaves. Process 1800 can be performed, for example, by the enclave client 1602 of FIG. 16. In box 1802, a first enclave is created on a first native enclave platform, and a certification report of the first enclave is created in box 1804. This first certification report (of the first enclave) can be checked in box 1806, for example, as described above with reference to box 1706 of FIG. 17. In box 1808, a safe operation is initiated at the first enclave, but is not completed. The state of the first enclave can optionally be locked so that it can be safely moved out of the first enclave in box 1810. For example, the state of the first enclave can be blocked for an identity type of the first enclave. Once the state of the enclave has been saved, the first enclave can be terminated (not drawn).
[0156] A second enclave is used starting at box 1812. In box 1812, the second enclave is instantiated on a second native platform. As in FIGS. 16 and 17, the second native platform may or may not be hosted on the same computer as the first native platform, and the first and second native platforms may be the same or different. A certification report for the second native platform is created in box 1814, and, optionally, this second certification report can be verified in box 1816. An identity value from the first and second certification reports can be compared in box 1818 to verify the equivalence of the first and second enclaves. In alternative modalities, the second enclave can be instantiated and the equivalence checked (boxes 1812 - 1818) before the safe operation is
Petition 870190061562, of 7/2/2019, p. 85/142
75/101 started in the first enclave in box 1808. To continue the safe operation started in the first enclave, the locked state of the first enclave can be copied to the second enclave and unlocked in box 1820. In box 1822, the safe operation is completed in second enclave (using the enclave state safely copied from the first enclave, if the state was copied).
DISTRIBUTED DATA LOCK [0157] FIG. 19 is a block diagram of an example of a distributed data lock system. Data blocking can be distributed across multiple enclaves, where these enclaves are hosted on separate native enclave platforms, and / or on separate computers. As explained above, the EnclaveSeal and EnclaveUnseal abstraction primitives can lock and unlock data for an enclave using a key tied to the native enclave platform or the physical computer on which the enclave is running. This can restrict unlocking only to enclaves hosted on the same computer or on the same native enclave platform instance. FIG. 19 describes a distributed data locking system, where data locking or unlocking can occur on a native platform or computer other than the native platform or computer hosting the enclave. The 1900 system includes the 1910, 1930, 1950 computers, with the 1902 network connecting the 1910 and 1930 computers, and the 1904 network connecting the 1930 and 1950 computers. The 1910 computer hosts the 1912 source enclave, from which the data to be being blocked can originate; the 1930 computer hosts a 1932 distributed lock enclave (DSE) to serve distributed lock and unlock requests; and the 1950 computer that hosts the 1952 destination enclave where previously blocked data is unlocked. As explained above with reference to FIG. 9, the
Petition 870190061562, of 7/2/2019, p. 86/142
76/101 enclaves 1912, 1932, 1952, can communicate with the abstraction platforms 1914, 1934, 1954, respectively, through an enclave abstraction protocol, and the abstraction platforms 1914, 1934, 1954, can communicate with native platforms 1916, 1936, 1956, respectively, through a native protocol. In alternative modes, one or more 1912, 1932, 1952 enclaves can be hosted directly on native platforms 1916, 1936, 1956, without an intermediate abstraction platform. Locked 1938 data can be locked data for DSE 1932 using a key associated with DSE 1932 or its native 1936 hosting platform. Locked 1938 data can be stored in a less protected location, such as on the 1930 computer outside the DSE 1932 secure enclave container, for example, anywhere else in the 1930 computer’s memory space or on a file system on a hard drive. [0158] The blocking of distributed data may include a DSE 1930 authentication for the source enclave, for example, through the DES 1932 certification on the 1902 network. Since the 1912 source enclave trusts the 1932 DSE, the source enclave 1912 can send sensitive data via a secure communication channel to DSE 1932 together with a blocking policy to block DSE 1932. DSE 1932 can then block data from the 1912 enclave itself and store the blocked data in unsafe storage. Later, the destination enclave 1952 can request previously blocked data. To unlock the data, DSE 1932 can authenticate the target 1952 enclave, for example, by certifying through a 1904 network, and verify that unlocking for the target 1952 enclave is allowed according to the locking policy provided by the enclave source 1912. DSE 1932 can unlock previously blocked data from the
Petition 870190061562, of 7/2/2019, p. 87/142
77/101 1912 source enclave, and then send the unlocked data via a secure communication channel to the destination 1952 enclave. Enclave data can be communicated securely to and from DSE 1932 via encryption of the enclave data over the 1902 and 1904 networks. For example, the enclave data sent over the 1902 network can be encrypted with a key generated during DSE 1932 certification for the 1912 source enclave, and the data sent over the 1904 network. can be encrypted with a key generated during the certification of the 1952 destination enclave to the 1932 DSE. Other secure communication channels are possible, such as by encryption with a destination public key, for example, a public key associated with the DSE or a public key associated with the target enclave.
[0159] The enclave identities used in blocking and distributed unlocking may or may not be abstract enclave identities. For example, in some modalities with an abstraction platform layer, a blocking policy, such as that specified by a source enclave and applied by a DSE, can identify allowed unlocked enclave identities where the allowed unlocked enclave identities are, for example, example, a list of abstract enclave identities, or a list of abstract identity types in combination with the abstract identity values of the source enclave. In other situations, a non-abstract identity can be used. For example, in some modalities, a DSE can be implemented with publicly available code, such that confidence in the DSE is confidence in the knowledge of your code as opposed to confidence in the author of your code. In this example, the certification of a DSE can be a signed scramble of all public DSE codes, and the entry for the scramble function may not include abstract identity values
Petition 870190061562, of 7/2/2019, p. 88/142
78/101 attributed by the author.
[0160] In some modalities the native platforms 1916, 1936, 1956 are separate native platforms because they are hosted on different computers 1910, 1930, 1950, even if the native platforms 1916, 1936, 1956, conform to the same version of the same native enclave platform architecture. In other modalities, the native platforms 1916, 1936, 1956, can conform to different platform architectures or different versions of the same native enclave platform architecture. The use of abstract identities in the blocking policy can facilitate hosting the target and source enclaves on different native enclave platform architectures.
[0161] In other modalities of blocking distributed data not drawn in FIG. 19, there may not be three separate computers (such as separate computers 1910, 1930, 1950). For example, the target and source enclaves can be on one computer (or perhaps on a single native platform), while DSE is on a separate computer. Alternatively, a DSE can be hosted on the same computer as both the computer hosting the source enclave and the computer hosting the destination enclave. In these modalities of blocking distributed data, the blocking and unlocking of the data are not completely local on a single computer, as described above in relation to the abstraction primitives EnclaveSeal and EnclaveUnseal. [0162] Distributed data blocking can be implemented in an API abstraction layer, such as by the abstraction platforms 1914, 1934, 1954. For example, the DistributedEnclaveSeal and DistributedEnclaveUnseal primitives are similar to the local EnclaveSeal and EnclaveUnseal primitive data blocks discussed. above.
Petition 870190061562, of 7/2/2019, p. 89/142
79/101
DWORD
DistributedEndaveSeal (
Jn_ SEALING ... POLICY sealingPolicy, _ln_reads_bytes_opt_ (dwPlaintextSize) LPCVOID pPalintext, DWORD Jn_ dwPlaintextSize, _ln_reads_bytes_opt_ (dwAuthdataSize) LPCVOID pAuthdata, DWORD Jn_ dwAuthdataSize, _Out_writes_bytes_to _ra (dwSealedtextSize) LPCVOID pSealedtext, DWORD Jnout_ dwSealedtextSize, Set <Enclaveldentity> SetOfTargetEnclaves)
[0163] DistributedEndaveSeal extends EndaveSeal by taking an additional SetOfTargetEnclaves parameter, which allows an enclave to call, such as the 1910 enclave, to specify a set of enclave identities that are authorized to unlock the data provided using the pPlaintext parameter. If no identity is provided through SetOfTargetEnclaves, a default authorized enclave identity can be assumed to be the identity of the blocking enclave, for example, ExactHash or InstanceHash of the blocking enclave.
[0164] The implementation of DistributedEndaveSeal, for example, as a method of the 1914 abstraction platform on the source enclave computer, may include the establishment of a secure communication channel with a DSE, such as through an encrypted message over the network 1902. The key (s) for this encryption can, for example, be generated during the certification process, as described above, or it can be any public key associated with the DSE 1932.
[0165] The DistributedEndaveSeal can be additionally
Petition 870190061562, of 7/2/2019, p. 90/142
80/101 generalized when taking an additional KeyForData parameter (not shown in the DistributedEnclaveSeal function prototype above). In some embodiments, several sets of data can be kept locked simultaneously by a single enclave or by a single enclave identity. In this case, KeyForData allows you to specify which data set is being blocked. KeyForData can be any type of data identifier, such as a string, a number, or a set of properties. In some modalities, the KeyForData can be an input parameter for the DistributedEnclaveSeal and be generated by the blocking enclave, effectively enabling the blocking enclave to name the data set. In other modalities, the KeyForData can be an output parameter, where the DSE generates the KeyForData identifier as the data is blocked.
DWORD
DistributedEnciaveUnseai (
Jn_reads_bytes_opt_ (dwSealedtextSize) LPCVOID pSealedtext, Jn_ DWORD wSealedtextSize, _ln_reads_bytes_opt_ (dwAuthdataSize) LPCVOID pAuthdata, Jn_ DWORD dwAuthdataSize, __Out_text
Key KeyForData,
Enclaveldentity identity [0166] DistributedEnciaveUnseai can be implemented on a 1954 abstraction platform, and operated in response to a request from a 1952 target enclave. DistributedEnciaveUnseai can establish a communication channel
Petition 870190061562, of 7/2/2019, p. 91/142
81/101
Secure with DSE 1932, for example, when encrypting messages with a key generated during the 1952 destination enclave certification for DSE 1932, or when encrypting messages sent to the destination enclave with a public key of the destination enclave. The DSE can verify an identity of the requesting (destination) enclave such as by certification, unlocking the requested blocked data, and securely sending the unlocked data to the requesting enclave. In modalities where the requesting enclave has multiple identities, a particular identity can be specified in the Identity parameter. In modalities where multiple enclave data sets are stored for a single enclave identity, the KeyForData parameter can specify which blocked data set (for the specified identity) is requested when using the same KeyForData value used in the DistributedEnclaveSeal when the data set it was blocked.
[0167] In some modalities, the identities of the enclaves authorized to unlock the data can be specified (as in the parameter SetOfTargetEnclaves) using public keys of the authorized target enclaves. In this modality, certification of the destination enclave for the DSE may not be necessary, but the unlocked data can then only be provided encrypted using one of the specified public keys. Assuming that only target enclaves have access to the corresponding private keys to decrypt, only target enclaves will have access to the unlocked data.
[0168] In modalities not drawn in FIG. 19, the functions of the distributed blocking enclave (DSE) 1932 can themselves be distributed across several DSEs. For example, DSE functionality can be distributed across multiple DSEs on multiple computers for fault tolerance and redundancy. In this example,
Petition 870190061562, of 7/2/2019, p. 92/142
82/101 any replicated DSE may be able to serve a lock or unlock request. Note that 1938 locked data, once locked / encrypted, can be safely stored anywhere, including being replicated through cloud storage servers.
[0169] Blocking distributed data can allow the movement of enclave workloads between computers. For example, the source enclave data blocked by the DSE can be state data from the source enclave on a first cloud server, which can be loaded into the destination enclave on a second cloud server after unlocking. This can be done in a manner similar to that described above with respect to FIG. 18. A secure operation can start execution in the source enclave. Later, perhaps after execution in a source enclave is interrupted, the state of the source enclave can be locked for a DSE, and then unlocked for a destination enclave when the target enclave is ready to continue the safe operation that was started in the source enclave.
[0170] FIG. 20 is an example of a flowchart for blocking and unlocking distributed data, as can be performed by a blocking enclave or DSE. Boxes 2002 - 2006 correspond to the blocking of distributed data, while boxes 2008 - 2010 correspond to the blocking of distributed data. In response to a request to block a set of enclave data originating from a source enclave, the blocking enclave (or DSE) can certify itself to the source enclave by submitting a quota or certification report to the source enclave at box 2002. The source enclave can verify the identity of the blocking enclave as a trusted and genuine blocking enclave by inspecting an identity value and signature on the blocking enclave certification report. In box 2004, the blocking enclave receives a list
Petition 870190061562, of 7/2/2019, p. 93/142
83/101 allowed and the enclave data to be blocked. These can be received via a secure channel as described above with reference to FIG. 19. In an optional 2006 box, the locking enclave can lock the data from the source enclave to itself, for example, if the data is stored outside a secure locking enclave container, such as in a locking system. computer files. To unlock data for a destination enclave, the destination enclave can certify itself for the blocking enclave, such as by providing a quota or certification report, in box 2008. In box 2010, an identity of the enclave of destination can be verified, such as when inspecting the certification report of the destination enclave. In box 2012, the blocking enclave determines whether the destination enclave is allowed to unlock the data from the source enclave by verifying that an authenticated identity of the destination enclave is included in the allowed list received with the data. Once the permission has been confirmed, the enclave data can be unlocked if it has been blocked, and then sent to the destination enclave via a secure channel in the 2014 box.
KEY SAFE ENCLAVE [0171] Safe keys can be implemented with enclaves. A key vault securely holds keys, such as keys to an encryption system to encrypt and decrypt data, for key vault customers. A key vault can additionally perform key operations, such as encrypting and decrypting the data, signing the data, and deriving new keys from an existing key. A key vault, when implemented as an enclave, can provide very secure storage and processing with secret encryption keys. Additionally, the software certification of a
Petition 870190061562, of 7/2/2019, p. 94/142
84/101 key safe enclave can provide high levels of security for a safe customer who is communicating with an authentic and reliable key safe. Highly secure systems can be built in a key safe enclave with a locked key safe, so a key stored inside the key safe is never released to any customer outside the key safe, and in some cases the key safe locked can only exist while stored inside (or possibly locked to) the key safe enclave.
[0172] FIG. 21 is a block diagram of an example of a key vault enclave. Enclave 2122 is a key vault within a secure enclave container of the second native enclave platform 216. In the example of FIG. 21, the 2112 key vault enclave client 2122 is also an enclave, and is hosted inside a secure enclave container of the first native 2116 enclave platform. The 2112, 2122 enclaves can interact with their respective 2116 native platforms. , 2126, through respective enclave abstraction platforms 2114, 2124. In other embodiments, one or both abstraction platforms 2114, 2124, may not exist where enclaves 2112 and / or 2122 interact directly with native platforms 2116, 2126.
[0173] The key vault enclave 2122 can communicate with the vault client 2112 through the communication channel 2150. In some embodiments, the communication channel 2112 can be a secure communication channel providing assurance of confidentiality, integrity and / or the timeliness of messages sent through the communication channel 2150. The confidentiality and integrity of such a secure communication channel can be established, for example, with encryption and signatures, as in FIGS. 2 and 3, using shared keys generated as part of a certification process,
Petition 870190061562, of 7/2/2019, p. 95/142
85/101 as in FIGS. 5 and 6.
[0174] Software certification provides security in part by providing assurance of the entity's identity on the other side of a communication channel. By certifying a 2122 key vault enclave for a vault client, the customer can obtain assurances that the 2122 key vault enclave is who it claims to be before sending a secret, such as a key or other cleartext data, to the key safe. The reverse is also true for customers who are also enclaves, as described in FIG. 21. By certifying a 2112 vault enclave to a 2122 vault vault enclave, the vault can obtain assurances that the customer is who he claims to be before revealing a secret, such as a key or other cleartext data, for the client.
[0175] Key safe systems with keys in a locked safe and derived keys, particularly where encryption keys are derived from a key in a locked safe, can be used to build a security system that is flexible and very secure. A key derivation function, which may or may not be public, can be used to generate multiple keys from a first key. The first key (a root secret) can be locked in a safe for the highest level of security, and the keys derived from the first key can be used for encryption purposes. If a derived key is compromised, a new derived key can be generated in an existing system without having to access or change the key vault that holds the first key.
[0176] An example of a key vault enclave (KVE) is a cloud-based key vault system that provides key storage, generation, derivation, distribution, encryption, decryption, and signatures using enclaves. The KVE can be identified by its exact shuffling (a shuffling of the contents of its secure container), or by an identifier
Petition 870190061562, of 7/2/2019, p. 96/142
86/101 arbitrary assigned by or associated with its creator. In the latter case, the enclave can be signed with the creator's private key to avoid confrontations and security breaches due to identifier collisions.
[0177] A key vault customer can interact with a key vault system using the following primitive examples. An example of a StoreKey function prototype is:
StoreKey ([in] Keyname, [in] KeyType, [in] KeyValue, [in] Policy)
StoreKey stores a given key in the key vault and associates it with a given name. The key type is also associated with the key and restricts what can be done with the key. For example, some keys should only be used for encryption, in addition to signatures, etc. And specific keys can only be used with specific encryption algorithms. The policy may specify policies to further restrict the use of the key. For example, you can specify a set of enclave identities that are allowed to retrieve the key and / or use the key. You can also specify temporal properties, for example, that the key must be destroyed on a certain date, or that the rate of operations using the key must be limited.
[0178] An example of a GenerateKey function prototype is: GenerateKey ([ín] keyName, [in] keyType, [in] Policy) [0179] GenerateKey generates a new key of a certain type and keeps it stored in a safe. key, for example, the key never leaves the key vault.
[0180] An example of a prototype GetKey function is: GetKey ([in] KeyName, [out] KeyValue) [0181] GetKey searches for a key stored inside the key vault. These primitives are usually implemented through a secure communication channel and the code that calls the primitive
Petition 870190061562, of 7/2/2019, p. 97/142
87/101 normally runs in a trusted environment. In such a context, it is often acceptable to recover a key from a key vault.
[0182] An example of the DeleteKey function prototype is: DeleteKey ([in] keyName) [0183] DeleteKey deletes a key from the key vault.
[0184] An example of a DeriveKey function prototype is: DeriveKey ([ln] newKeyName, [in] KeyName, [In] kdfldentifier, [In] AdditionalData) [0185] DeriveKey uses a cryptographic key derivation (KDF) function identified by kdfldentifier to derive a new key based on the key identified by KeyName and the data is passed in AdditionalData.
[0186] An example of an Encrypt function prototype is:
Encrypt ([in] KeyName, [in] algorithm, [in] data, [out] encrypted Data) [0187] Encrypt encrypts the data with the key identified by KeyName, using the requested algorithm.
[0188] An example of a Decrypt function prototype is:
Decrypt ([ln] KeyName, [In] algorithm, [in] encrypted Data, [out] data) [0189] Decrypt decrypts the data with a key identified by KeyName, using the requested algorithm.
[0190] An example of a Sign function prototype is:
Sign ([in] KeyName, [in] algorithm, [in] data, [out] signature) [0191] Sign signs data with the key identified by KeyName, using the requested algorithm.
[0192] An example of a VerifySignature function prototype is: VerifySignature ([in] KeyName, [in] algorithm, [in] signature, [out} bool signaturelsCorrect)
Petition 870190061562, of 7/2/2019, p. 98/142
88/101 [0193] VerifySignature verifies the signature with the key identified by KeyName, using the requested algorithm.
[0194] All of the above key vault primitives can be implemented by establishing a secure channel with KVE. The channel can be established using certification and performing a Diffie-Hellman key exchange as described above with respect to FIGS. 5 and
6. After the communication channel has been established, the request is sent securely through the channel and the response is read from the channel. The channel can provide guarantees of confidentiality and integrity of the data exchanged.
[0195] In another mode, the first time KVE executes, it generates a pair of public / private keys and generates a quota for the public key. Then write the quota and public key, while keeping the private key within the enclave. The public key and quota can then be distributed to all systems / codes that wish to use the key vault. In this case, the implementation of the above primitives checks the quota to make sure it is talking to a genuine KVE, and then encrypts the requests using the KVE public key. As part of the request, the implementation of the primitives may include a key to code and the integrity protects the results sent from KVE. This modality can provide a two-way communication channel without certification.
[0196] FIG. 22 is an example of a flow chart for some operations in a key vault enclave. Process 2200 starts at box 2202 by securely storing, within the key vault enclave, a key used in an encryption system. The key can be used, for example, to encrypt and decrypt data, generate a cryptographic signature, or it can only be used as a root key from which other keys are derived. The key
Petition 870190061562, of 7/2/2019, p. 99/142
89/101 can be securely stored in the key vault enclave, for example, by storing the key within the memory space of the enclave secure container. In other embodiments, the key can be kept safe outside the secure enclave container by locking the key data to the key vault enclave, or it can be kept secure by remote locking with a locking enclave distributed as described with reference to FiGS. 19e20.
[0197] In box 2204, the key vault enclave performs a certification process to certify the key vault enclave's identity to the vault client. This can give the customer a guarantee that the key vault is not an imposter and can be a credible creditor of secrets such as the key or the data to be encrypted. The key vault enclave certification may include sending the voucher customer a certification report or a key voucher enclave certification quota. The key vault client can then verify the integrity of the certification report by verifying a signature on the certification report with a public key associated with the key vault enclave's native enclave platform. For example, the key vault certification report 2122 can be generated by the second native platform 2126, and the vault client 2112 can verify the signature on the report using the public key associated with the second native platform 2126. This process of certification can also generate keys used for a secure communication channel between the vault client and the key vault enclave, for example, as shown in FIGS. 5 and 6. The certification report may include a key vault enclave identity that can be determined in various ways as described above, for example, in relation to FIGS. 14 and 15. Identity can, for example, be based on a shuffling of the entire
Petition 870190061562, of 7/2/2019, p. 100/142
90/101 contents of the key vault secure container, a scramble of only a unique identifier assigned to the author / creator of the key vault enclave, or a scramble of a combination of the contents of the container and a unique identifier. [0198] Some key vault enclave operations may require guarantees of the vault customer's identity. For example, decrypting data or disclosing a key (as with the primitives Decrypt and GetKey) may require such a guarantee. In these situations, if a vault customer is also an enclave, option box 2208 includes a certification process for verifying, through the key vault enclave, the identity of the vault customer. The certification process for box 2208 may include receiving, in the key vault enclave, a quota or certification report from the vault customer.
[0199] In optional box 2210, a secure communication channel can be established between the key vault and the key vault enclave. Secure communication may be required to transfer secrets between the vault client and the key vault enclave, such as keys or data to be encrypted. The certification process of box 2204 or 2208 can generate keys that can be used to create a secure communication channel between the vault client and the key vault enclave, for example, as shown in FIGS. 5 and 6. Alternatively, any public key for a message destination can be used to send a message securely.
[0200] In box 2212, a key operation, such as one of the key safe primitives described above, can be performed inside the key safe enclave. During this operation, key data can be stored only in the address space of the secure container of the key vault enclave. Examples of primitives include DeriveKey, Decrypt, Sign and others.
Petition 870190061562, of 7/2/2019, p. 101/142
91/101 [0201] Case 2200 assumes that the key vault enclave already knows the key. Note that for some primitives or key vault enclave operations, such as StoreKey or GenerateKey, the order of operations may be different from that described in process 2200. For example, for GenerateKey, the key generation operation (as in box 2212 ) will occur prior to the safe storage operation of box 2202. Such an order of operation is described in FIG. 23, boxes 2302 - 2308.
[0202] FIG. 23 is an example of a flowchart for creating and using a key safe enclave with a key locked in the safe. In boxes 2302 - 2308 of process 2300, a new key is derived within the key vault enclave. In boxes 2310 - 2316, the newly derived key is used to perform a decoding operation. This is an example of using the key locked in the safe, whereby all key operations are performed with the key safe enclave and the key is never provided to the safe customer. In addition, the new key in this example may never exist outside the key vault enclave, because it was created (derived) from within the key vault enclave itself, and never supplied to the key vault enclave from a safe customer or from anywhere else. For some modalities and key usage policies, a key locked in the safe may be ephemeral in that it never leaves the safe container of the key safe enclave, even after locking the key to the key safe enclave. Such an ephemeral key, as could happen with a derived key used to temporarily protect a communication channel, can cease to exist anywhere when the container of the key vault enclave is destroyed or finalized. While the process of FIG. 23 illustrates how a key locked in the safe can be used, the process of FIG. 23 can also be
Petition 870190061562, of 7/2/2019, p. 102/142
92/101 used with a key that is not locked in the safe, for example if the key usage policy allows the key to be returned to the customer who requested its creation.
[0203] In box 2302, the key vault enclave attests itself to the vault customer. This may be required by the customer because the customer will provide a secret to be encrypted in box 2312. In box 2304, the key vault enclave can receive, for example, from the vault client, an indication of a usage policy key. The indication can, for example, be a data structure that specifies the policy, or it can be an identifier to be used with a key usage policy record. The key usage policy, in itself, may indicate that this key should never be provided to any safe customer. In box 2306, a new key is derived from a previously known root key, for example, with the DeriveKey primitive described above. A request (not described) to derive the new key can be received by the key vault enclave from, for example, the vault client. In box 2308, the newly derived key can be safely stored according to the received key usage policy.
[0204] The vault client can vouch for itself for the key vault enclave in box 2310. A certification process may include receiving, in the key vault enclave, a quota or certification report from the vault client . The received key usage policy may restrict some or all of the uses of the new key to requests from applicants who are authenticated through software certification. In boxes 2312 - 2316, a decryption operation, like the Decrypt primitive above, is performed using the derived key in box 2306. In other modalities, other operations can be performed with a key locked in the safe, such as encryption , signature, verification of a
Petition 870190061562, of 7/2/2019, p. 103/142
93/101 signature and derivation of another new key from the derived key in box 2306 (deriving a second key generation from the root key). In box 2312, an encrypted data buffer is received from the vault client. The received encrypted data is decoded with the derived key in box 1314, and the resulting decoded data (in a decoded data buffer) is sent to the vault client via a secure communication channel in box 2316.
[0205] In one embodiment, a method for unlocking enclave data comprises:
[0206] The secure storage, by a blocking enclave hosted on a first native enclave platform, of an allowed list and associated enclave data from a source enclave, where the allowed list includes a list of one or more identities enclave allowed to unlock the enclave data;
[0207] Receipt of a destination certification report from a destination enclave hosted on a second native enclave platform;
[0208] Deriving a destination identity from the destination enclave from the destination certification report;
[0209] Determination of access permission when verifying that the destination identity is included in the allowed list; and [0210] Sending the enclave data from the blocking enclave to the destination enclave.
[0211] In one embodiment, the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[0212] In one embodiment, the allowed list is a list of abstract identities; and further comprises:
[0213] Receipt of a source certification report from the
Petition 870190061562, of 7/2/2019, p. 104/142
94/101 source enclave; and [0214] Deriving an allowed identity value from a source enclave certification report and an abstract identity type in the allowed list; and [0215] Where verification that the target identity is included in the allowed list includes checking that a target identity value is the same as the allowed identity value.
[0216] In one embodiment, the enclave data sent is encrypted, and further comprising:
[0217] A certification process between the blocking enclave and the destination enclave;
[0218] Encryption of the enclave data with the key generated during the certification process to create the encrypted enclave data; and [0219] Where the enclave data sent to the destination enclave is the encrypted enclave data.
[0220] In one embodiment, a plurality of enclave data sets are securely stored by the blocking enclave for an enclave identity in the allowed list, and further comprising:
[0221] The reception, from the destination enclave, of a selection key that indicates one among the plurality of enclave data sets.
[0222] In one embodiment, a method to unlock data from the enclave comprising:
[0223] The sending, to a blocking enclave hosted on a first native enclave platform, of a first certification report of a destination enclave hosted on a second native enclave platform; and [0224] The reception, from the blocking enclave, of the data of
Petition 870190061562, of 7/2/2019, p. 105/142
95/101 enclave associated with an enclave identity derived from the first certification report.
[0225] In one embodiment, the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[0226] In one embodiment, the enclave data received is encrypted, and further comprising:
[0227] A certification process between the blocking enclave and the destination enclave; and [0228] The decryption of the enclave data received with a key generated during the certification process.
[0229] In one embodiment, the enclave data is the state data of a source enclave after partially completing a safe processing operation, and further comprising:
[0230] Continuation of the safe processing operation in the destination enclave using the state data of the source enclave.
[0231] In one embodiment, the method still comprises:
[0232] The sending, to the blocking enclave, of a selection key indicating which enclave data set, of a plurality of enclave data sets associated with an identity derived from the first certification report, must be sent to the destination enclave.
[0233] In one embodiment, a system comprising at least one processor and a memory storing instructions therein that, when executed by the system, cause at least:
[0234] Storing in a secure way, by means of a blocking enclave hosted on a first native enclave platform, of a permitted list and associated with the enclave data from a
Petition 870190061562, of 7/2/2019, p. 106/142
96/101 source enclave, where the allowed list includes a list of one or more enclave identities allowed to unlock the enclave data;
[0235] Receipt of a destination certification report from a destination enclave hosted on a second native enclave platform;
[0236] Deriving a destination identity from the destination enclave from the destination certification report;
[0237] Determining access permission when verifying that the destination identity is included in the allowed list; and [0238] Sending the enclave data from the blocking enclave to the destination enclave.
[0239] In one embodiment, the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[0240] In one embodiment, the allowed list is a list of abstract identity types; the instructions still provoke, at least:
[0241] The receipt of a source certification report from a source enclave; and [0242] Deriving an allowed identity value from a source enclave source certification report and an abstract identity type in the allowed list; and [0243] Where verification that the target identity is included in the allowed list includes checking that a target identity value is the same as a permitted identity value. [0244] In one modality, the enclave data sent is encrypted, and the instructions still provoke, at least:
[0245] A certification process between the blocking enclave and the destination enclave;
[0246] Encryption of enclave data with a generated key
Petition 870190061562, of 7/2/2019, p. 107/142
97/101 during the certification process to create the encrypted enclave data; and [0247] Where the enclave data sent to the destination enclave is the encrypted enclave data.
[0248] In one embodiment, a plurality of enclave data sets are securely stored by a blocking enclave for an enclave identity in the allowed list, and the instructions still cause at least:
[0249] The reception, from the destination enclave, of a selection key that indicates one among the plurality of enclave data sets.
[0250] In one embodiment, a system comprising at least one processor and a memory storing, in itself, instructions that, when executed by the system, cause at least:
[0251] The sending, to a blocking enclave hosted on a first native enclave platform, of a first certification report of a destination enclave hosted on a second native enclave platform; and [0252] The receipt, from the blocking enclave, of the enclave data associated with an enclave identity derived from the first certification report.
[0253] In one embodiment, the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[0254] In one modality, the enclave data received is encrypted, and the instructions still provoke, at least:
[0255] A certification process between the blocking enclave and the destination enclave; and [0256] The decryption of the enclave data received with a key generated during the certification process.
Petition 870190061562, of 7/2/2019, p. 108/142
98/101 [0257] In one embodiment, the enclave data is the state data of a source enclave after partially completing a safe processing operation, and the instructions still trigger at least: [0258] The processing operation continues in the destination enclave using the state data of the source enclave.
[0259] In one mode, the instructions still provoke, at least:
[0260] The sending, to the blocking enclave, of a selection key that indicates the enclave data set, among a plurality of enclave data sets associated with an identity derived from the first certification report, should be sent to the destination enclave.
[0261] Each of the processes, methods and algorithms described in the preceding sections can be incorporated into, and fully or partially automated by, code modules executed by one or more computers or computer processors. The code modules can be stored in any type of non-transitory computer-readable medium or computer storage device, such as hard drives, solid state memory, optical drives and / or the like. The processes and algorithms can be implemented partially or completely in a specific application circuit. The results of the disclosed processes and process steps can be stored, persistently or otherwise, in any type of non-transitory computer storage such as volatile or non-volatile storage. The various features and processes described above can be used independently of each other, or can be combined in several ways. All possible combinations and subcombination are predicted to fall
Petition 870190061562, of 7/2/2019, p. 109/142
99/101 within the scope of this disclosure. In addition, certain methods or process blocks may be omitted in some implementations. The methods and processes described in this document are also not limited by any particular sequence, and the blocks or states related to them can be executed in another sequence that is appropriate. For example, the blocks or states described can be executed in a different order than specifically disclosed, or several blocks or states can be combined into a single block or state. The example blocks or states can be executed in series, in parallel, or in some other way. Blocks or states can be added or removed from the modalities disclosed as an example. The example systems and components described in this document can be configured differently than described. For example, elements can be added to, removed from, or rearranged in comparison to the disclosed example modalities.
[0262] It will also be appreciated that various items are illustrated as being stored in memory or in storage while being used, and that those items or portions thereof can be transferred between memory and other storage devices for purposes of memory management and data integrity. Alternatively, in other modalities, some or all software modules and / or systems can run in memory on another device and communicate with the computer systems illustrated by means of communication between computers. In addition, in some embodiments, some or all of the systems and / or modules may be implemented or provided in other ways, such as at least partially in firmware and / or hardware, including, but not limited to, one or more integrated circuits application-specific (ASICs), standard integrated circuits, controllers
Petition 870190061562, of 7/2/2019, p. 110/142
100/101 (for example, when executing appropriate instructions, and including embedded microcontrollers and / or controllers), programmable field gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc. Some or all modules, systems and data structures can also be stored (for example, as software instructions or structured data) in a computer-readable medium, such as a hard drive, memory, network or media item handheld to be read by an appropriate drive or through an appropriate connection. For the purposes of this specification and the claims, the phrase "computer-readable storage medium" and variations thereof, do not include waves, signals, and / or other intangible and / or transitory means of communication. Data systems, modules and structures can also be transmitted as generated data signals (for example, as part of a charged wave or other digital or analog propagated signal) on a variety of computer-readable transmission media, including media based on cables / wires and wirelessly based, and that can take a variety of shapes (for example, as part of a multiplexed or single analog signal, or as multiple discrete digital frames or packages). Such computer program products can also take other forms in other modalities. In this sense, the present disclosure can be practiced with other configurations of computer systems.
[0263] The conditional language used in this document, such as, among others, "may", "could", "could", "can", "for example", and the like, unless specifically defined otherwise, or otherwise understood within the context as used, it is generally intended to convey that certain modalities include, while other modalities do not include, certain resources, elements and / or stages. Thus, such a conditional language does not
Petition 870190061562, of 7/2/2019, p. 111/142
101/101 generally intends to imply that resources, elements and / or stages are in any case required for one or more modalities or that one or more modalities necessarily include the logic for decision, with or without a request or input from the author, if these resources, elements and / or steps are included or must be performed in any particular mode. The terms "comprising", "including", "having", and the like, are synonymous and are used in an inclusive, open manner, and do not exclude additional elements, resources, actions, operations and so on. In addition, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some or all of the elements on the list.
[0264] While certain example modalities have been described, these modalities have been presented as an example only and are not intended to limit the scope of the inventions disclosed in this document. Thus, nothing in the description mentioned is intended to imply that any particular resource, feature, stage, module, or block is necessary or indispensable. In fact, the new methods and systems described in this document can be incorporated in a variety of other ways; in addition, various omissions, substitutions and changes in the form of the methods and systems described in this document can be made without departing from the spirit of the inventions disclosed in this document. The accompanying claims and their equivalents are intended to cover these forms or changes as they would fall within the scope and spirit of certain of the inventions disclosed in this document.

权利要求:
Claims (15)
[1]
1. Method for unlocking the data enclave, characterized by comprising:
store securely, by a blocking enclave housed on a first native enclave platform, an allowed list and associated enclave data from an enclave source, where the allowed list includes a list of one or more enclave identities allowed to unlock the enclave data;
receive a destination certification report for a destination enclave hosted on a second native enclave platform;
derive a destination identity from the destination enclave from the destination certification report;
determine access permission by verifying that the target identity is included in the allowed list; and send the enclave data from the blocking enclave to the destination enclave.
[2]
2. Method according to claim 1, characterized by the fact that:
the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[3]
3. Method according to claim 1, characterized by the fact that the allowed list is a list of abstract identity types; and additionally comprising:
receive a source certification report from the source enclave; and derive a permitted identity value from a source enclave certification report and a
Petition 870190061562, of 7/2/2019, p. 113/142
2/5 type of abstract identity in the allowed list; and where verifying that the destination identity is included in the permitted Hsta includes verifying that a destination identity value is the same as the permitted identity value.
[4]
4. Method according to claim 1, characterized by the fact that the enclave data sent is encrypted, and additionally comprising:
a certification process between the blocking enclave and the destination enclave;
encode the enclave data with a key generated during the certification process to create the encrypted enclave data; and where the enclave data sent to the destination enclave is the encrypted enclave data.
[5]
Method according to claim 1, characterized in that a plurality of enclave data sets are securely stored by the blocking enclave for an enclave identity in the allowed list, and further comprising:
receive, from the destination enclave, a selection key indicating one of the plurality of enclave data sets.
[6]
6. System characterized by comprising at least one processor and a memory in which instructions are stored which, when executed by the system, cause at least:
store securely, via a blocking enclave housed on a first native enclave platform, a whitelist and associated enclave data from a source enclave, where the permitted Hsta includes a list of one or more identity of enclave allowed to unlock the enclave data;
Petition 870190061562, of 7/2/2019, p. 114/142
3/5 receive a destination certification report from a destination enclave hosted on a second native enclave platform;
derive a destination identity from the destination enclave from the destination certification report;
determine an access permission when verifying that the target identity is included in the allowed list; and send the enclave data from the blocking enclave to the destination enclave.
[7]
7. System according to claim 6, characterized by the fact that:
the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[8]
8. System according to claim 6, characterized by the fact that the allowed list is a list of abstract identity types; the instructions still make at least:
receive a source certification report from the source enclave; and derive an allowed identity value from a source enclave certification report and an abstract identity type in the allowed list; and wherein checking whether the target identity is included in the allowed list includes checking whether a target identity value is the same as the permitted identity value.
[9]
9. System according to claim 6, characterized by the fact that the enclave data sent is encrypted, and the instructions still make at least:
a certification process between the blocking enclave and the destination enclave;
Petition 870190061562, of 7/2/2019, p. 115/142
4/5 encrypt the enclave data with a key generated during the certification process to create the encrypted enclave data; and where the enclave data sent to the destination enclave is the encrypted enclave data.
[10]
10. System according to claim 6, characterized by the fact that a plurality of enclave data sets are securely stored by the blocking enclave for an enclave identity in the allowed list, and the instructions still cause, at least any less:
receive, from a destination enclave, a selection key that indicates one of the plurality of enclave data sets.
[11]
11. System characterized by comprising at least one processor and a memory in which instructions are stored which, when executed by the system, cause at least:
send, to a blocking enclave hosted on a first native enclave platform, a first certification report for a target enclave hosted on a second native enclave platform; and receives, from the blocking enclave, the enclave data associated with an enclave identity derived from the first certification report.
[12]
12. System according to claim 11, characterized by the fact that:
the first native enclave platform is on a first computer and the second native enclave platform is hosted on a second computer.
[13]
13. System according to claim 11, characterized by the fact that the enclave data received are
Petition 870190061562, of 7/2/2019, p. 116/142
5/5 encrypted, and the instructions still make at least:
a certification process between the blocking enclave and the destination enclave; and decode the enclave data received with a key generated during the certification process.
[14]
14. System according to claim 11, characterized by the fact that the enclave data is state data of a source enclave after partially completing a safe processing operation, and the instructions still do at least:
continue the secure processing operation in the target enclave using the state data of the source enclave.
[15]
15. System according to claim 11, characterized by the fact that the instructions still cause at least:
send, to the blocking enclave, a selection key that indicates which enclave data set, among the plurality of enclave data sets associated with an identity derived from the first certification report, should be sent to the enclave of destiny.

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3574438B1|2021-05-26|Data unsealing with a sealing enclave

---

US10911451B2|2021-02-02|Cross-platform enclave data sealing

---

US10372945B2|2019-08-06|Cross-platform enclave identity

---

US10867029B2|2020-12-15|Enclave client abstraction model

---

EP3846060A1|2021-07-07|Key vault enclave

---

US11036875B2|2021-06-15|Dependent enclave binaries

---

IL267948A|2022-01-01|Data sealing with a sealing enclave

---

AU2017395731B2|2022-01-20|Abstract enclave identity

---

US10877785B2|2020-12-29|Enclave abstraction model

---

US20180212760A1|2018-07-26|Nested enclave identity

同族专利:

---

公开号 | 公开日

---

SG11201905460SA|2019-08-27|

---

CL2019002010A1|2019-12-13|

---

US10530777B2|2020-01-07|

---

IL267947D0|2019-09-26|

---

CO2019007874A2|2019-07-31|

---

CA3048892A1|2018-08-02|

---

IL267947A|2021-05-31|

---

JP2020505698A|2020-02-20|

---

AU2017395733A1|2019-07-04|

---

EP3574438B1|2021-05-26|

---

AU2017395733B2|2021-11-25|

---

KR20190108576A|2019-09-24|

---

RU2019126645A3|2021-04-14|

---

RU2019126645A|2021-02-26|

---

RU2759331C2|2021-11-11|

---

WO2018140163A1|2018-08-02|

---

ZA201903703B|2020-10-28|

---

MX2019008691A|2019-09-10|

---

PH12019550114A1|2020-12-07|

---

EP3574438A1|2019-12-04|

---

CN110199287A|2019-09-03|

---

US20180212971A1|2018-07-26|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

US20110085667A1|2009-10-09|2011-04-14|Adgregate Markets, Inc.|Various methods and apparatuses for securing an application container|

---

US8312260B2|2009-10-09|2012-11-13|Sas Institute Inc.|Dynamic analytical differentiator for obfuscated functions in complex models|

---

US8977842B1|2010-02-05|2015-03-10|Symantec Corporation|Hypervisor enabled secure inter-container communications|

---

US8972746B2|2010-12-17|2015-03-03|Intel Corporation|Technique for supporting multiple secure enclaves|

---

US8832452B2|2010-12-22|2014-09-09|Intel Corporation|System and method for implementing a trusted dynamic launch and trusted platform module using secure enclaves|

---

US8176283B1|2011-09-26|2012-05-08|Google Inc.|Permissions of objects in hosted storage|

---

US9009854B2|2012-12-19|2015-04-14|Intel Corporation|Platform-hardened digital rights management key provisioning|

---

WO2014196966A1|2013-06-04|2014-12-11|Intel Corporation|Technologies for hardening the security of digital information on client platforms|

---

WO2015060858A1|2013-10-24|2015-04-30|Intel Corporation|Methods and apparatus for protecting software from unauthorized copying|

---

EP3084667A4|2013-12-19|2017-07-26|Intel Corporation|Policy-based trusted inspection of rights managed content|

---

US9355262B2|2013-12-27|2016-05-31|Intel Corporation|Modifying memory permissions in a secure processing environment|

---

US9792427B2|2014-02-07|2017-10-17|Microsoft Technology Licensing, Llc|Trusted execution within a distributed computing system|

---

US9489534B2|2014-10-23|2016-11-08|Northrop Grumman Systems Corporation|Multi-level security system for enabling secure file sharing across multiple security levels and method thereof|

---

US9558330B2|2014-12-23|2017-01-31|Intel Corporation|Technologies for digital rights managment of 3D printable models|

---

US9749323B2|2015-03-27|2017-08-29|Intel Corporation|Technologies for secure server access using a trusted license agent|

---

US9710401B2|2015-06-26|2017-07-18|Intel Corporation|Processors, methods, systems, and instructions to support live migration of protected containers|

---

US10462135B2|2015-10-23|2019-10-29|Intel Corporation|Systems and methods for providing confidentiality and privacy of user data for web browsers|

---

US10565370B2|2015-12-24|2020-02-18|Intel Corporation|System and method for enabling secure memory transactions using enclaves|

---

US10469265B2|2016-03-31|2019-11-05|Intel Corporation|Technologies for secure inter-enclave communications|US10790978B2|2016-05-25|2020-09-29|Intel Corporation|Technologies for collective authorization with hierarchical group keys|

---

US10311217B2|2016-12-09|2019-06-04|Microsoft Technology Licensing, Llc|Application piracy prevention with secure enclave protection of automatically modularized functions|

---

US10911451B2|2017-01-24|2021-02-02|Microsoft Technology Licensing, Llc|Cross-platform enclave data sealing|

---

US10931652B2|2017-01-24|2021-02-23|Microsoft Technology Licensing, Llc|Data sealing with a sealing enclave|

---

US10972265B2|2017-01-26|2021-04-06|Microsoft Technology Licensing, Llc|Addressing a trusted execution environment|

---

US10897360B2|2017-01-26|2021-01-19|Microsoft Technology Licensing, Llc|Addressing a trusted execution environment using clean room provisioning|

---

US10897459B2|2017-01-26|2021-01-19|Microsoft Technology Licensing, Llc|Addressing a trusted execution environment using encryption key|

---

US10726120B2|2017-03-31|2020-07-28|Intel Corporation|System, apparatus and method for providing locality assertion between a security processor and an enclave|

---

US10990516B1|2017-06-08|2021-04-27|Liberty Mutual Insurance Company|Method, apparatus, and computer program product for predictive API test suite selection|

---

CN108306740B|2018-01-22|2020-07-31|华中科技大学|Intel SGX state consistency protection method and system|

---

US10659054B2|2018-02-23|2020-05-19|Nxp B.V.|Trusted monotonic counter using internal and external non-volatile memory|

---

US10831506B2|2018-04-05|2020-11-10|Phoenix Technologies Ltd.|Local oversight and provisioning of BIOS activity|

---

US10867053B2|2018-06-26|2020-12-15|Sri International|Creating software packages for performing secure computations|

---

WO2020167977A1|2019-02-12|2020-08-20|Payfone, Inc.|Systems and methods for porting communication devices|

---

CN109922056B|2019-02-26|2021-09-10|创新先进技术有限公司|Data security processing method, terminal and server thereof|

---

US10652081B1|2019-06-24|2020-05-12|Capital One Services, Llc|Facilitating resilient and fault tolerant asynchronous messaging|

法律状态:
2021-10-13| B350| Update of information on the portal [chapter 15.35 patent gazette]|

优先权:

---

申请号 | 申请日 | 专利标题

---

US15/414,505|US10530777B2|2017-01-24|2017-01-24|Data unsealing with a sealing enclave|

---

PCT/US2017/067454|WO2018140163A1|2017-01-24|2017-12-20|Data unsealing with a sealing enclave|

---